Setting up Android development environment on a Linux host

Using a PC with FC-15 Linux…

Install eclipse.

Follow all steps on the android development web page to install the Adroid SDK and ADT plugin for eclipse.

If you ever need access to Android’s sources you will need git and a tool named ‘repo’ written by google, which works on top of git. The tool itself maybe quite useful but google definitely did a very poor job in making it available – the link to download it is VERY hard to find on their site. At time of writing of this page it was here. If this link does not work then the command to get it is:
        $ curl https://android.git.kernel.org/repo > ~/.repo
This is will download it to your home directory. Move it somewhere within your path and make sure you make it executable… (chmod 755..)

Install VirtualBox (see here if there’s any problems with this step).

Get the android-x86 ISO (I got version 2.2 but you may choose something else…). This is so you can create an Android VirtualBox machine.

Keep in mind that ‘2.2’ above is the Android Linux version – not the version of the kernel! This can get especially confusing, since the versions of the distribution and the kernel are so close! (2.2 vs 2.6.xx)

Once you’re done with that – setup your Android vbox VM and fire it up. When setting up the machine make sure to give it enough RAM and hard disk space (512MB to 1 GB RAM and at least 10-15GB of disk space. The latter is especially important if you plan to follow the below section and split your /dev/sda1 HD into two partitions)

Splitting the android-x86 harddisk

This section describes how to split Android’s hard disk (the /dev/sda device inside the virtual VBox installation of Android-x86) into two. If this is of no interest to you you may skip this section. Personally, I think it is quite useful to have an extra data partition. Why is it useful? Well.. for one thing – you don’t even have a place to store files in your stock android-x86 installation. Splitting the harddisk will give you one more partition where you can store any data you want…

In general – just follow the instructions provided here to re-size and split your initial sda1 partition into sda1 and sda2…

Some more useful links on the topic:
http://forums.virtualbox.org/viewtopic.php?p=29276#2927 – a lot of information about VirtualBox’s .VDI file format.
http://wiki.przemoc.net/projects/start#vidma – a utility to resize your existing VDI file (in case you don’t give it enough space right from the start and then need to resize it later. Keep in mind that this is a serious pain in the behind. After you resize the VDI using the vidma util you are very likely to get an error saying that the UUID of your VDI file is already registered (as a different disk). In this case use the info provided in the first link to locate the UUID inside the VDI file header and change it.Changing just one number should be enough.
And… yet another problem… after you increase the VDI size – the size of /dev/sda inside your VM will reflect the fact that it is now larger but the partitions will still be of the old size. So you will need run fdisk or cfdisk and fix this problem. I just added a third partition taking up the entire available space and fixed my problem (the problem being that initially I created an Android VM with a HD size of 1 GB, thinking that ‘hey, it’s just a phone, who’d need more than one gig of space on a phone and then I found that I needed to install the kernel sources there, which is 500MB and I ran out of space 🙂 So I did all this jumping through hoops described above, increased my HD to 16GB (hope this will be enough…!), than added sda3).

All text from now on assumes you are working in the Android VM (unless specified otherwise).

Fix your keyboard settings (unless you want to see the Asian characters at the bottom of the screen each time you press a key). To do this go to Settings -> “Language and keyboard settings” and select your Language and layout and then leave only the “Android keyboard” option checked.

In your Android VM start the terminal (go to Dev Tools -> Terminal Emulator).

When Android is running your sda HD partitions are not in /dev/sdaXX but in /dev/block/sdaXX. Mount the extra partition that you created somewhere in your disk namespace (I used /data/mnt_sda2). Use ssh and scp to copy here all the files you need from your host machine (Android Linux should have recognized your network hardware and assigned it an IP address). In my case I wanted to install the VirtualBox Guest Additions so I copied the Guest Additions ISO and the tarred kernel sources. You can get the kernel sources from http://www.android-x86.org/getsourcecode). You now should have all the files that you need on your extra partition.

Mount the ISO.
No, you can’t just use mount -t iso9660 -o loop -r file.iso mountpoint. I mean – hey, if it works – great, they fixed the problem! But if does not then you’ll need some more voodoo magic to get it mounted, namely use losetup:

# losetup /dev/block/loop1
# mount -t iso9660 -r /dev/block/loop1

You should now have the contents of the Guest Additions CD available under the directory specified in mountpoint. 🙂

4 thoughts on “Setting up Android development environment on a Linux host

  1. Hi, thanks for trying vidma. 🙂

    If you perform in-place resize of VDI (remember to shutdown VM where the VDI is attached to before), then lack of UUID change is ok. UUID changing will be supported in future and bunch of other nice features (look at vidma’s issues, i.e. todo list). Unfortunately I don’t have time atm to develop vidma, but I’ll surely return to it in future.

    You can change UUID using following command:
    VBoxManage internalcommands sethduuid [UUID]

    • Hi przemoc, thanks for comments. I fixed the missing UUID in the square brackets in your first comment and updated the 2nd one to reflect this, hope you don’t mind…

      Your vidma util worked great, btw. I understand what you’re saying about editing the VDI file in-place but since this was my first time trying vidma I was a little shy and decided I’d work with a copy of the VDI file… hence the UUID problem … 🙂

      Btw, I am not done with this post yet so I will some more info her soon. This blog is really a transcript of my daily experiences as I hack around and play with various Linux stuff and it’s mostly for my personal use, so that in the future I can come back to stuff that I’ve done before in case I ever get stuck again on the same problem…

      Cheers and thanks for the great tool vidma.

      • Nice to hear that apart from UUID inconvenience you did not have any problems with vidma. Definitely this tool is not yet great, but will be till 2013, at least I hope so. 🙂

        Working on a copy is perfectly fine, though, even recommended (see also: vidma(1) man page). I was defending lack of UUID change, not really suggesting in-place resize. According to Murphy’s laws: If anything can go wrong, it will. So even if vidma works correctly, electricity loss during resizing will make your image corrupted with possible loss of data. In some future versions it will be possible to recover (at least partially) after such accidents too.

        As it’s stated in vidma usage information: USE AT YOUR OWN RISK! NO WARRANTY!
        IOW I won’t take responsibility for any corrupted image, but if you provide enough details about the accident, then I’ll help you to not let it happen again or at least minimize damages next time.

Leave a Reply

Your email address will not be published. Required fields are marked *