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://gitorious.org/xdandroid-eclair/manifest.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 https://android.git.kernel.org/repo >~/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://gitorious.org/xdandroid-eclair/manifest.git
$ ~/bin/repo sync

/* Create a buildspec.mk file with build configuration */

$ cat >buildspec.mk <<__EOF__
TARGET_PRODUCT := xdandroid_msm_us
TARGET_BUILD_VARIANT := eng
TARGET_BUILD_TYPE := release
__EOF__

/* 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 buildspec.mk 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.