The Beginnings of an XDANDROID Build Environment

One of the ongoing goals of the XDANDROID project has been to build an entire system from the Android open-source project. This is a relatively simple task on its own: you check out the tree, configure it quickly (or just let the build system choose the generic defaults), and `make` it. Of course, with a generic build, there will be many pieces of hardware (and some software) left unsupported by the resulting images. For XDANDROID, we’d like to have a fully (or at least mostly) functional set of images as a result of a simple `make` command, after the obligatory configuration. With some recent work that I’ve pushed into a few new source repositories on gitorious, we hope to be on our way to achieving this goal. Read on to see what we’ve got and how to use it.

In that gitorious link above are all of the Android repositories that we’re using for the AOSP build environment project. The most important of these, from a user’s perspective, is the manifest repository. This repository contains only one crucial file, used by the Android repo utility to download all of the relevant source code for the Android tree. Eventually, users (who are actually packagers or “chefs” by XDA lingo) will be able to do the following for a working AOSP XDANDROID tree:

$ repo init -u git://

After a long time of checking out, or downloading, the sources, you’ll have a full tree to build from. We host our own repo manifest for one reason: to pull in any custom source code we need for a working XDANDROID environment. At the moment, the most important such code is an XDANDROID vendor directory tree, which helps configure the Android build system to build images for an XDANDROID phone. This is the workhorse of the build system, which provides all the changes needed for us to seamlessly drop in a compiled system image with no changes. With the images that are generated from the source tree, using the XDANDROID vendor configuration, we can then boot a device. In fact, the device will boot without any changes to our own rootfs, initramfs and kernel. So, what kind of magic is needed to build it all? Here’s a preliminary recipe:

The following instructions may be outdated. Check the XDANDROID wiki for up-to-date information.

/* Grab Android’s repo utility */

$ curl >~/bin/repo
$ chmod +x ~/bin/repo

/* In some directory where you want it all, set up and sync repo with our manifest */

$ mkdir xdandroid-aosp ; cd xdandroid-aosp
$ ~/bin/repo init -u git://
$ ~/bin/repo sync

/* Create a file with build configuration */

$ cat > <<__EOF__
TARGET_PRODUCT := xdandroid_msm_us

/* Build the final product */

$ make

So, after that long build process is finished, you end up with a few filesystem images in the out/target/product/msm/ directory. I personally like to be able to drop that system image right onto the SD card as it is, so in the file, I also add this line: TARGET_USERIMAGES_USE_EXT2 := true – this will require some ext2 utils in your PATH, so you might need PATH="$PATH:/sbin" before the last make command.

So, you can either repack the image as system.sqsh yourself, or have AOSP build you some ext2 images and stick system.img on your SD card as system.ext2. Then boot up and hope for the best!

This is all very early in development, so only people with deep knowledge of the Android system and the hardware should take on such an adventure. As always, I’m available as stinebd on both XDA-Developers forums and on freenode IRC in #xdandroid. Good luck and have fun.

2 thoughts on “The Beginnings of an XDANDROID Build Environment”

  1. It might be worth noting a couple of other things…

    If you’re building an Eclair system, you might as well take advantage of the just-in-time support in Dalvik for (hopefully) faster performance from the VM. This can be done by adding the following line to WITH_JIT := true

    Also, it may be necessary to set the following to allowing market apps to be installed (I’m still not quite sure, but it seems the default codename, REL, prevents it): PLATFORM_VERSION_CODENAME := AOSP This has been fixed since a certain 2.0 update to the AOSP tree.

Leave a Reply