On the previous post, we got the AOSP code into our environment and learned how that process works. The _repo _tool and the Manifest project goes hand-in-hand, managing the 200+ git repositories, all part of the AOSP.

Now that we have all the code locally, we need to get all those lines of code into a nice package we can eventually install on a device. The nice guys in Google brought us some nice utilities to help with that. To initialize your environment with those new functions and environment variables, you need to run the command:

$ source <working dir>/build/

Note: I’m using Mac OS with “oh-my-zsh” and “zsh” as my default shell. When running this command from a shell other than “bash”, you’ll get a warning that only bash is supported. From my experience, I can tell that I never ran into a problem. If you know otherwise - let me know, otherwise - I highly recommend this configuration regardless of AOSP work.

Now, we can get this party started..

Build targets

There are several devices we can build our new Android ROM for (remember what ROM is?), with different feature combinations and build types that we can use. In order to pick the desired configuration, we’ll use lunch. The lunch command can take the configuration name as an argument, or picked by the user from a list. A configuration name is structured this way:


PRODUCT - This part describes the set of modules to be included, among other configurations. We can include only some of the packages in the system, or all of them, depending on the “flavor” we want our new ROM to be. A “package”, for this matter, can be an app, a system component, sounds, locales, fonts or even just a regular files that are copied to the final product. We can also set different system properties for a specific product. There are several predefined products we can use:

generic - default set of packages.

full - a full set of packages, with most necessary apps and all locales

aosp - Basically inherits everything from full.

sdk - packages needed to build the SDK. I’ll elaborate about the SDK on a separate post.

There are also sub-products for specific uses. For instance, you can have full_flo to build the full product for the Nexus 7 (codename “flo”), providing you have the necessary drivers (more on that later). To see what’s included in each product, check the .mk files under <working dir>/build/target/product and also under /device/<vendor>/<device codename>.

BUILDTYPE - Selects the modules to install and set some default settings or behaviors of the product. Each variant can accept only modules who set, in their file, the LOCAL_MODULE_TAGS to at least one of the tags it approves (tag examples: debug, samples, tests and more) . The valid build types are:

eng - this variant will have some development tools and predefined settings that developers need (e.g. USB debugging enabled).

user - this is the variant for a product that suppose to go out to the users. Will use only modules that the end-user will need and more restricted settings.

userdebug - A combination of the user and eng variants. It’s intended for users testing your environment, but not developing it.