Device-specific binaries are flashed to the various partitions just described. The framework needs to be compiled for a specific target. The target represents the device to which you want to flash the binaries.
Note
Build variants: The build system provides several types of builds. These builds result in minor changes to the final binaries.
engineering
(eng
): Is the default option. Plain make defaults to this. Includes all modules tagged eng
, user
, debug
, and userdebug
. ADB is enabled and will run commands as root user.
user
: This is intended for the final production build. ADB is disabled and will not run commands as the root user.
userdebug
: Basically, the same as user
, but the system is debuggable and ADB is enabled by default.
All of these tags are assigned to projects in the Android.mk
file. If you open up any of these files, it is mentioned with the help of the LOCAL_MODULE_TAGS
command.
Navigate to your Android source directory and include the build environment as usual. (source build/envsetup.sh
).
To obtain a list of available targets supported by the source version you are working with, use the
lunch
command in a terminal:lunch The output (for 2.3.4_r1) should look like: You're building on Linux Lunch menu... pick a combo: 1. generic-eng 2. simulator 3. full_passion-userdebug full_crespo-userdebug
Before you initiate a build for a particular target, you need to obtain the proprietary binaries for the phone and unzip them into your source directory. Usually, an agreement and unzipping script accompany the binaries. After scrolling through the agreement, type
I AGREE
and press Enter. The required files will be unzipped to the correct location in the source directory.Here is an example of downloading the Orientation Sensor for Nexus S, Build GRJ22:
Navigate to https://developers.google.com/android/nexus/drivers#crespogrj22.
Download the ZIP file for Orientation Sensor and place it in the Android sources directory on your computer.
Unzip it to the current directory. A file called
extract-akm-crespo.sh
will be created.Execute it and scroll down the agreement. At the end, type in
I AGREE
. Then the binaries will be extracted.Follow a similar procedure for the other files of your device.
Note
The binaries for the Nexus One have to be extracted from the device itself. In the source directory,
ANDROID_SRC/device/htc/passion
, a shell script exists to pull the needed binaries directly from the device. Connect your Nexus One to a computer and over adb execute the following:./extract-files.sh
This will pull various proprietary binaries and copy them to the appropriate location in the source directory (
ANDROID_SRC/vendor/
).
The lunch
command is part of the build environment. It provides a list of available targets you can build with your current source distribution. In all the distributions, the simulator and generic-eng
targets are available. Simulator was used before the QEMU emulator became available. This target is now deprecated and should not be used.
We can build the code for a generic target (the emulator), or a simulator target (currently outdated, this existed when the QEMU emulator was not ready). The more interesting options are full_passion-userdebug
and full_crespo-userbedug
. The first one represents the Google Nexus One device. Passion is the code name for that device. Similarly, the latter represents the Google Nexus S.
Google Nexus One – Passion
Google Nexus S – Crespo + crespo4g
Galaxy Nexus – Maguro + Toro
Therefore, based on your target device, you can select the desired build target and execute a make.
Although Android is an open source project, certain hardware drivers are closed source. These include the graphics drivers, the WiFi chipset drivers on certain models, orientation sensors, the radio baseband software, and camera drivers. Therefore, if you create a build just with the source downloaded from the Android GIT tree, certain phone functions will not work. For example, if the correct radio image was not included, you will not be able to make and receive phone calls. However, these drivers are made available in binary format for download from https://developers.google.com/android/nexus/drivers.
In the event that something went wrong with your custom code and the device becomes unusable, you will need to restore it to a working state. Google provides Factory images for its developer devices. They contain the usual system.img
, boot.img
, and recovery.img
images that will restore the device to its factory state. These are available at https://developers.google.com/android/nexus/images.
Note
The files for the Nexus One are not available at that location, and you will need to obtain it from an alternate location, such as Cyanogen Mod or modaco.
You may need to execute the following command after including proprietary binaries to make sure they are included in the generated software images:
make clobber