32
Initializing a Build Environment This section describes setting up local work environment, using Repo to get the Android files, and building the files on your machine. To build the Android source files, it requires Linux . Choosing a Branch Some of the requirements for build environment are determined by which version of the source code you plan to compile. See Build Numbers for a full listing of branches you may choose from. You may also choose to download and build the latest source code (called "master"), in which case you will simply omit the branch specification when you initialize the repository. Once you have selected a branch, follow the appropriate instructions below to set up your build environment. Setting up a Linux build environment These instructions apply to all branches, including master. The Android build is routinely tested in house on recent versions of Ubuntu LTS (10.04), but most distributions should have the required build tools available. Reports of successes or failures on other distributions are welcome. For Gingerbread (2.3.x) and newer versions, including the master branch, a 64- bit environment is required. Older versions can be compiled on 32-bit systems. You will need: Python 2.5 -- 2.7, which you can download from python.org . GNU Make 3.81 -- 3.82, which you can download from gnu.org , JDK 6 if you wish to build Gingerbread or newer; JDK 5 for Froyo or older. You can download both from java.sun.com . Git 1.7 or newer. You can find it at git-scm.com . Installing the JDK The Sun JDK is no longer in Ubuntu's main package repository. In order to download it, you need to add the appropriate repository and indicate to the system which JDK should be used.

Initializing a Build Environment

Embed Size (px)

Citation preview

Page 1: Initializing a Build Environment

Initializing a Build Environment

This section describes setting up local work environment, using Repo to get the Android files, and building

the files on your machine. To build the Android source files, it requires Linux .

Choosing a Branch

Some of the requirements for build environment are determined by which version of the source code you

plan to compile. See Build Numbers for a full listing of branches you may choose from. You may also

choose to download and build the latest source code (called "master"), in which case you will simply omit

the branch specification when you initialize the repository.

Once you have selected a branch, follow the appropriate instructions below to set up your build

environment.

Setting up a Linux build environment

These instructions apply to all branches, including master.

The Android build is routinely tested in house on recent versions of Ubuntu LTS (10.04), but most

distributions should have the required build tools available. Reports of successes or failures on other

distributions are welcome.

For Gingerbread (2.3.x) and newer versions, including the master branch, a 64-bit environment is

required. Older versions can be compiled on 32-bit systems.

You will need:

Python 2.5 -- 2.7, which you can download from python.org.

GNU Make 3.81 -- 3.82, which you can download from gnu.org,

JDK 6 if you wish to build Gingerbread or newer; JDK 5 for Froyo or older. You can download

both from java.sun.com.

Git 1.7 or newer. You can find it at git-scm.com.

Installing the JDK

The Sun JDK is no longer in Ubuntu's main package repository. In order to download it, you need to add

the appropriate repository and indicate to the system which JDK should be used.

Java 6: for Gingerbread and newer

Page 2: Initializing a Build Environment

$ sudo add-apt-repository "deb http://archive.canonical.com/ lucid partner"

$ sudo apt-get update

$ sudo apt-get install sun-java6-jdk

Installing required packages on Ubuntu

You will need a 64-bit version of Ubuntu. Ubuntu 10.04 is recommended.

$ sudo apt-get install git-core gnupg flex bison gperf build-essential \

zip curl zlib1g-dev libc6-dev lib32ncurses5-dev ia32-libs \

x11proto-core-dev libx11-dev lib32readline5-dev lib32z-dev \

libgl1-mesa-dev g++-multilib mingw32 tofrodos python-markdown \

libxml2-utils xsltproc

Configuring USB Access

Under GNU/linux systems (and specifically under Ubuntu systems), regular users can't directly access

USB devices by default. The system needs to be configured to allow such access.

The recommended approach is to create a file /etc/udev/rules.d/51-android.rules (as the root user)

and to copy the following lines in it. <username> must be replaced by the actual username of the user

who is authorized to access the phones over USB.

# adb protocol on passion (Nexus One)

SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", ATTR{idProduct}=="4e12", MODE="0600", OWNER="<username>"

# fastboot protocol on passion (Nexus One)

SUBSYSTEM=="usb", ATTR{idVendor}=="0bb4", ATTR{idProduct}=="0fff", MODE="0600", OWNER="<username>"

# adb protocol on crespo/crespo4g (Nexus S)

SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", ATTR{idProduct}=="4e22", MODE="0600", OWNER="<username>"

# fastboot protocol on crespo/crespo4g (Nexus S)

Page 3: Initializing a Build Environment

SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", ATTR{idProduct}=="4e20", MODE="0600", OWNER="<username>"

# adb protocol on stingray/wingray (Xoom)

SUBSYSTEM=="usb", ATTR{idVendor}=="22b8", ATTR{idProduct}=="70a9", MODE="0600", OWNER="<username>"

# fastboot protocol on stingray/wingray (Xoom)

SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", ATTR{idProduct}=="708c", MODE="0600", OWNER="<username>"

# adb protocol on maguro/toro (Galaxy Nexus)

SUBSYSTEM=="usb", ATTR{idVendor}=="04e8", ATTR{idProduct}=="6860", MODE="0600", OWNER="<username>"

# fastboot protocol on maguro/toro (Galaxy Nexus)

SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", ATTR{idProduct}=="4e30", MODE="0600", OWNER="<username>"

# adb protocol on panda (PandaBoard)

SUBSYSTEM=="usb", ATTR{idVendor}=="0451", ATTR{idProduct}=="d101", MODE="0600", OWNER="<username>"

# fastboot protocol on panda (PandaBoard)

SUBSYSTEM=="usb", ATTR{idVendor}=="0451", ATTR{idProduct}=="d022", MODE="0600", OWNER="<username>"

# usbboot protocol on panda (PandaBoard)

SUBSYSTEM=="usb", ATTR{idVendor}=="0451", ATTR{idProduct}=="d00f", MODE="0600", OWNER="<username>"

# usbboot protocol on panda (PandaBoard ES)

SUBSYSTEM=="usb", ATTR{idVendor}=="0451", ATTR{idProduct}=="d010", MODE="0600", OWNER="<username>"

Those new rules take effect the next time a device is plugged in. It might therefore be necessary to

unplug the device and plug it back into the computer.

Setting up ccache

You can optionally tell the build to use the ccache compilation tool. Ccache acts as a compiler cache that

can be used to speed-up rebuilds. This works very well if you do "make clean" often, or if you frequently

switch between different build products.

Page 4: Initializing a Build Environment

Put the following in your .bashrc or equivalent.

export USE_CCACHE=1

By default the cache will be stored in ~/.ccache. If your home directory is on NFS or some other non-local

filesystem, you will want to specify the directory in your .bashrc as well.

export CCACHE_DIR=<path-to-your-cache-directory>

The suggested cache size is 50-100GB. You will need to run the following command once you have

downloaded the source code.

prebuilt/linux-x86/ccache/ccache -M 50G

This setting is stored in the CCACHE_DIR and is persistent.

Using a separate output directory

By default, the output of each build is stored in the out/ subdirectory of the matching source tree.

On some machines with multiple storage devices, builds are faster when storing the source files and the

output on separate volumes. For additional performance, the output can be stored on a filesystem

optimized for speed instead of crash robustness, since all files can be re-generated in case of filesystem

corruption.

To set this up, export the OUT_DIR_COMMON_BASE variable to point to the location where your output

directories will be stored.

export OUT_DIR_COMMON_BASE=<path-to-your-out-directory>

The output directory for each separate source tree will be named after the directory holding the source

tree.

For instance, if you have source trees

as /source/master1 and /source/master2 and OUT_DIR_COMMON_BASE is set to /output, the

output directories will be/output/master1 and /output/master2.

It's important in that case to not have multiple source trees stored in directories that have the same name,

as those would end up sharing an output directory, with unpredictable results.

This is only supported on branches newer than 4.0.x (IceCreamSandwich).

Page 5: Initializing a Build Environment

Downloading the Source TreeInstalling Repo

Repo is a tool that makes it easier to work with Git in the context of Android. For more information about

Repo, see Version Control.

To install, initialize, and configure Repo, follow these steps:

Make sure you have a bin/ directory in your home directory, and that it is included in your path:

Page 6: Initializing a Build Environment

$ mkdir ~/bin

$ PATH=~/bin:$PATH

Download the Repo script and ensure it is executable:

$ curl https://dl-ssl.google.com/dl/googlesource/git-repo/repo > ~/bin/repo

$ chmod a+x ~/bin/repo

For version 1.17, the SHA-1 checksum for repo is

ddd79b6d5a7807e911b524cb223bc3544b661c28

Initializing a Repo client

After installing Repo, set up your client to access the android source repository:

Create an empty directory to hold your working files. If you're using MacOS, this has to be on a

case-sensitive filesystem. Give it any name you like:

$ mkdir WORKING_DIRECTORY

$ cd WORKING_DIRECTORY

Run repo init to bring down the latest version of Repo with all its most recent bug fixes. You

must specify a URL for the manifest, which specifies where the various repositories included in

the Android source will be placed within your working directory.

$ repo init -u https://android.googlesource.com/platform/manifest

To check out a branch other than "master", specify it with -b:

$ repo init -u https://android.googlesource.com/platform/manifest -b android-4.0.1_r1

When prompted, please configure Repo with your real name and email address. To use the Gerrit

code-review tool, you will need an email address that is connected with a registered Google

account. Make sure this is a live address at which you can receive messages. The name that you

provide here will show up in attributions for your code submissions.

Page 7: Initializing a Build Environment

A successful initialization will end with a message stating that Repo is initialized in your working directory.

Your client directory should now contain a .repo directory where files such as the manifest will be kept.

Getting the files

To pull down files to your working directory from the repositories as specified in the default manifest, run

$ repo sync

The Android source files will be located in your working directory under their project names. The initial

sync operation will take an hour or more to complete. For more aboutrepo sync and other Repo

commands, see Version Control.

Using authentication

By default, access to the Android source code is anonymous. To protect the servers against excessive

usage, each IP address is associated with a quota.

When sharing an IP address with other users (e.g. when accessing the source repositories from beyond a

NAT firewall), the quotas can trigger even for regular usage patterns (e.g. if many users sync new clients

from the same IP address within a short period).

In that case, it is possible to use authenticated access, which then uses a separate quota for each user,

regardless of the IP address.

The first step is to create a password from the password generator and to save it in ~/.netrc according to

the instructions on that page.

The second step is to force authenticated access, by using the following manifest

URI: https://android.googlesource.com/a/platform/manifest. Notice how the /a/ directory prefix

triggers mandatory authentication. You can convert an existing client to use mandatory authentication

with the following command:

$ repo init -u https://android.googlesource.com/a/platform/manifest

Troubleshooting network issues

When downloading from behind a proxy (which is common in some corporate environments), it might be

necessary to explicitly specify the proxy that is then used by repo:

$ export HTTP_PROXY=http://<proxy_user_id>:<proxy_password>@<proxy_server>:<proxy_port>

Page 8: Initializing a Build Environment

$ export HTTPS_PROXY=http://<proxy_user_id>:<proxy_password>@<proxy_server>:<proxy_port>

More rarely, Linux clients experience connectivity issues, getting stuck in the middle of downloads

(typically during "Receiving objects"). It has been reported that tweaking the settings of the TCP/IP stack

and using non-parallel commands can improve the situation. You need root access to modify the TCP

setting:

$ sudo sysctl -w net.ipv4.tcp_window_scaling=0

$ repo sync -j1

Using a local mirror

When using many clients, especially in situations where bandwidth is scarce, it is better to create a local

mirror of the entire server content, and to sync clients from that mirror (which requires no network

access).

These instructions assume that the mirror is created in /usr/local/aosp/mirror. The first step is to create

and sync the mirror itself, which uses close to 10GB of network bandwidth and a similar amount of disk

space. Notice the --mirror flag, which can only be specified when creating a new client:

$ mkdir -p /usr/local/aosp/mirror

$ cd /usr/local/aosp/mirror

$ repo init -u https://android.googlesource.com/mirror/manifest --mirror

$ repo sync

Once the mirror is synced, new clients can be created from it. Note that it's important to specify an

absolute path:

$ mkdir -p /usr/local/aosp/master

$ cd /usr/local/aosp/master

$ repo init -u /usr/local/aosp/mirror/platform/manifest.git

$ repo sync

Finally, to sync a client against the server, the mirror needs to be synced against the server, then the

client against the mirror:

Page 9: Initializing a Build Environment

$ cd /usr/local/aosp/mirror

$ repo sync

$ cd /usr/local/aosp/master

$ repo sync

It's possible to store the mirror on a LAN server and to access it over NFS, SSH or Git. It's also possible

to store it on a removable drive and to pass that drive around between users or between machines.

Verifying Git Tags

Load the following public key into your GnuPG key database. The key is used to sign annotated tags that

represent releases.

$ gpg --import

Copy and paste the key(s) below, then enter EOF (Ctrl-D) to end the input and process the keys.

-----BEGIN PGP PUBLIC KEY BLOCK-----

Version: GnuPG v1.4.2.2 (GNU/Linux)

mQGiBEnnWD4RBACt9/h4v9xnnGDou13y3dvOx6/t43LPPIxeJ8eX9WB+8LLuROSV

lFhpHawsVAcFlmi7f7jdSRF+OvtZL9ShPKdLfwBJMNkU66/TZmPewS4m782ndtw7

8tR1cXb197Ob8kOfQB3A9yk2XZ4ei4ZC3i6wVdqHLRxABdncwu5hOF9KXwCgkxMD

u4PVgChaAJzTYJ1EG+UYBIUEAJmfearb0qRAN7dEoff0FeXsEaUA6U90sEoVks0Z

wNj96SA8BL+a1OoEUUfpMhiHyLuQSftxisJxTh+2QclzDviDyaTrkANjdYY7p2cq

/HMdOY7LJlHaqtXmZxXjjtw5Uc2QG8UY8aziU3IE9nTjSwCXeJnuyvoizl9/I1S5

jU5SA/9WwIps4SC84ielIXiGWEqq6i6/sk4I9q1YemZF2XVVKnmI1F4iCMtNKsR4

MGSa1gA8s4iQbsKNWPgp7M3a51JCVCu6l/8zTpA+uUGapw4tWCp4o0dpIvDPBEa9

b/aF/ygcR8mh5hgUfpF9IpXdknOsbKCvM9lSSfRciETykZc4wrRCVGhlIEFuZHJv

aWQgT3BlbiBTb3VyY2UgUHJvamVjdCA8aW5pdGlhbC1jb250cmlidXRpb25AYW5k

cm9pZC5jb20+iGAEExECACAFAknnWD4CGwMGCwkIBwMCBBUCCAMEFgIDAQIeAQIX

Page 10: Initializing a Build Environment

gAAKCRDorT+BmrEOeNr+AJ42Xy6tEW7r3KzrJxnRX8mij9z8tgCdFfQYiHpYngkI

2t09Ed+9Bm4gmEO5Ag0ESedYRBAIAKVW1JcMBWvV/0Bo9WiByJ9WJ5swMN36/vAl

QN4mWRhfzDOk/Rosdb0csAO/l8Kz0gKQPOfObtyYjvI8JMC3rmi+LIvSUT9806Up

hisyEmmHv6U8gUb/xHLIanXGxwhYzjgeuAXVCsv+EvoPIHbY4L/KvP5x+oCJIDbk

C2b1TvVk9PryzmE4BPIQL/NtgR1oLWm/uWR9zRUFtBnE411aMAN3qnAHBBMZzKMX

LWBGWE0znfRrnczI5p49i2YZJAjyX1P2WzmScK49CV82dzLo71MnrF6fj+Udtb5+

OgTg7Cow+8PRaTkJEW5Y2JIZpnRUq0CYxAmHYX79EMKHDSThf/8AAwUIAJPWsB/M

pK+KMs/s3r6nJrnYLTfdZhtmQXimpoDMJg1zxmL8UfNUKiQZ6esoAWtDgpqt7Y7s

KZ8laHRARonte394hidZzM5nb6hQvpPjt2OlPRsyqVxw4c/KsjADtAuKW9/d8phb

N8bTyOJo856qg4oOEzKG9eeF7oaZTYBy33BTL0408sEBxiMior6b8LrZrAhkqDjA

vUXRwm/fFKgpsOysxC6xi553CxBUCH2omNV6Ka1LNMwzSp9ILz8jEGqmUtkBszwo

G1S8fXgE0Lq3cdDM/GJ4QXP/p6LiwNF99faDMTV3+2SAOGvytOX6KjKVzKOSsfJQ

hN0DlsIw8hqJc0WISQQYEQIACQUCSedYRAIbDAAKCRDorT+BmrEOeCUOAJ9qmR0l

EXzeoxcdoafxqf6gZlJZlACgkWF7wi2YLW3Oa+jv2QSTlrx4KLM=

=Wi5D

-----END PGP PUBLIC KEY BLOCK-----

After importing the keys, you can verify any tag with

$ git tag -v TAG_NAME

If you haven't set up ccache yet, now would be a good time to do it.

Page 11: Initializing a Build Environment

Building the System

The basic sequence of build commands is as follows:

Page 12: Initializing a Build Environment

Initialize

Initialize the environment with the envsetup.sh script. Note that replacing "source" with a single dot

saves a few characters, and the short form is more commonly used in documentation.

$ source build/envsetup.sh

or

$ . build/envsetup.sh

Choose a Target

Choose which target to build with lunch. The exact configuration can be passed as an argument, e.g.

$ lunch full-eng

The example above refers to a complete build for the emulator, with all debugging enabled.

If run with no arguments lunch will prompt you to choose a target from the menu.

All build targets take the form BUILD-BUILDTYPE, where the BUILD is a codename referring to the

particular feature combination:

Build name Device Notes

full emulator fully configured with all languages, apps, input methods

full_maguro maguro full build running on Galaxy Nexus GSM/HSPA+ ("maguro")

full_panda panda full build running on PandaBoard ("panda")

and the BUILDTYPE is one of the following:

Buildtype Use

user limited access; suited for production

userdebu like "user" but with root access and debuggability; preferred for debugging

Page 13: Initializing a Build Environment

Buildtype Use

g

eng development configuration with additional debugging tools

For more information about building for and running on actual hardware, see Building for devices

Build the Code

Build everything with make. GNU make can handle parallel tasks with a -jN argument, and it's common

to use a number of tasks N that's between 1 and 2 times the number of hardware threads on the

computer being used for the build. E.g. on a dual-E5520 machine (2 CPUs, 4 cores per CPU, 2 threads

per core), the fastest builds are made with commands between make -j16 and make -j32.

$ make -j4

Run It!

You can either run your build on an emulator or flash it on a device. Please note that you have already

selected your build target with lunch, and it is unlikely at best to run on a different target than it was built

for.

Flash a Device

To flash a device, you will need to use fastboot, which should be included in your path after a successful

build. Place the device in fastboot mode either manually by holding the appropriate key combination at

boot, or from the shell with

$ adb reboot bootloader

Once the device is in fastboot mode, run

$ fastboot flashall -w

The -w option wipes the /data partition on the device; this is useful for your first time flashing a particular

device, but is otherwise unnecessary.

For more information about building for and running on actual hardware, see Building for devices

Page 14: Initializing a Build Environment

Emulate an Android Device

The emulator is added to your path automatically by the build process. To run the emulator, type

$ emulator

Using ccache

ccache is a compiler cache for C and C++ that can help make builds faster. In the root of the source tree,

do the following:

$ export USE_CCACHE=1

$ export CCACHE_DIR=/<path_of_your_choice>/.ccache

$ prebuilt/linux-x86/ccache/ccache -M 20G

You can watch ccache being used by doing the following:

$ watch -n1 -d prebuilt/linux-x86/ccache/ccache -s

On OSX, you should replace linux-x86 with darwin-x86.

Troubleshooting Common Build ErrorsWrong Java Version

If you are attempting to build froyo or earlier with Java 1.6, or gingerbread or later with Java

1.5, make will abort with a message such as

************************************************************

You are attempting to build with the incorrect version

of java.

Your version is: WRONG_VERSION.

The correct version is: RIGHT_VERSION.

Please follow the machine setup instructions at

Page 15: Initializing a Build Environment

https://source.android.com/source/download.html

************************************************************

This may be caused by

failing to install the correct JDK as specified on the Initializing page. Building Android requires

Sun JDK 5 or 6 depending on which release you are building.

another JDK that you previously installed appearing in your path. You can remove the offending

JDK from your path with:

$ export PATH=${PATH/\/path\/to\/jdk\/dir:/}

Python Version 3

Repo is built on particular functionality from Python 2.x and is unfortunately incompatible with Python 3. In

order to use repo, please install Python 2.x:

$ apt-get install python

Case Insensitive Filesystem

If you are building on an HFS filesystem on Mac OS X, you may encounter an error such as

************************************************************

You are building on a case-insensitive filesystem.

Please move your source tree to a case-sensitive filesystem.

************************************************************

Please follow the instructions on the Initializing page for creating a case-sensitive disk image.

No USB Permission

On most Linux systems, unprivileged users cannot access USB ports by default. If you see a permission

denied error, follow the instructions on the Initializing page for configuring USB access.

If adb was already running and cannot connect to the device after getting those rules set up, it can be

killed with adb kill-server. That will cause adb to restart with the new configuration.

Page 16: Initializing a Build Environment
Page 17: Initializing a Build Environment

Building for devices

This page complements the main page about Building with information that is specific to individual

devices.

The supported devices with the current release are the Galaxy Nexus, Motorola Xoom, and Nexus S.

Galaxy Nexus is supported only in GSM/HSPA+ configuration "maguro" and only if it was originally sold

with a "yakju" or "takju" operating system.

The Motorola Xoom is supported in the Wi-fi configuration "wingray" sold in the USA.

Nexus S is supported in the GSM configuration "crespo".

In addition, PandaBoard a.k.a. "panda" is supported in the master branch only, but is currently considered

experimental. The specific details to use a PandaBoard with the Android Open-Source Project are in the

file device/ti/panda/README in the source tree.

Nexus One a.k.a. "passion" is obsolete, was experimental in gingerbread and unsupported, and can't be

used with newer versions of the Android Open-Source Project.

Android Developer Phones (ADP1 and ADP2, a.k.a. "dream" and "sapphire") are obsolete, were

experimental and unsupported in froyo, and can't be used with newer versions of the Android Open-

Source Project.

No CDMA devices are supported in the Android Open-Source Project.

Building fastboot and adb

If you don't already have those tools, fastboot and adb can be built with the regular build system. Follow

the instructions on the page about building, and replace the mainmake command with

$ make fastboot adb

Booting into fastboot mode

During a cold boot, the following key combinations can be used to boot into fastboot mode, which is a

mode in the bootloader that can be used to flash the devices:

Device Keys

maguro Press and hold both Volume Up and Volume Down, then press and hold Power

Page 18: Initializing a Build Environment

Device Keys

panda Press and hold Input, then press Power

wingray Press and hold Volume Down, then press and hold Power

crespo Press and hold Volume Up, then press and hold Power

passion Press and hold the trackball, then press Power

sapphire Press and hold Back, then press Power

dream Press and hold Back, then press Power

Also, on devices running froyo or later where adb is enabled, the command adb reboot bootloader can

be used to reboot from Android directly into the bootloader with no key combinations.

Unlocking the bootloader

It's only possible to flash a custom system if the bootloader allows it.

This is the default setup on ADP1 and ADP2.

On Nexus One, Nexus S, Xoom, and Galaxy Nexus, the bootloader is locked by default. With the device

in fastboot mode, the bootloader is unlocked with

$ fastboot oem unlock

The procedure must be confirmed on-screen, and deletes the user data for privacy reasons. It only needs

to be run once.

Note that on the Nexus S, Motorola Xoom and on Galaxy Nexus, all data on the phone is erased, i.e. both

the applications' private data and the shared data that is accessible over USB, including photos and

movies. Be sure to make a backup of any precious files you have before unlocking the bootloader.

On Nexus One, the operation voids the warranty and is irreversible.

On Nexus S, Xoom, and Galaxy Nexus, the bootloader can be locked back with

Page 19: Initializing a Build Environment

$ fastboot oem lock

Note that this erases user data on Xoom (including the shared USB data).

Obtaining proprietary binaries

Starting with IceCreamSandwich, the Android Open-Source Project can't be used from pure source code

only, and requires additional hardware-related proprietary libraries to run, specifically for hardware

graphics acceleration.

Official binaries for Nexus S, Galaxy Nexus, and PandaBoard can be downloaded from Google's Nexus

driver page, which add access to additional hardware capabilities with non-Open-Source code.

When a device is suppoted in the master branch, the binaries for the most recent numbered release are

the ones that should be used in the master branch.

There are no official binaries for Nexus One, ADP2 or ADP1.

Extracting the proprietary binaries

Each set of binaries comes as a self-extracting script in a compressed archive. After uncompressing each

archive, run the included self-extracting script from the root of the source tree, confirm that you agree to

the terms of the enclosed license agreement, and the binaries and their matching makefiles will get

installed in the vendor/hierarchy of the source tree.

Cleaning up when adding proprietary binaries

In order to make sure that the newly installed binaries are properly taken into account after being

extracted, the existing output of any previous build needs to be deleted with

$ make clobber

Picking and building the configuration that matches a device

The steps to configure and build the Android Open-Source Project are described in the page

about Building.

The recommended builds for the various devices are available through the lunch menu, accessed when

running the lunch command with no arguments:

Device Branch Build configuration

maguro android-4.0.4_r2.1 or master full_maguro-userdebug

Page 20: Initializing a Build Environment

Device Branch Build configuration

panda master full_panda-userdebug

wingray android-4.0.4_r2.1 or master full_wingray-userdebug

crespo android-4.0.4_r2.1 or master full_crespo-userdebug

passion android-2.3.7_r1 full_passion-userdebug

sapphire

android-2.2.3_r1 full_sapphire-userdebug

dream android-2.2.3_r1 full_dream-userdebug

Flashing a device

Set the device in fastboot mode if necessary (see above).

Because user data is typically incompatible between builds of Android, it's typically better to delete it

when flashing a new system.

$ fastboot erase cache

$ fastboot erase userdata

An entire Android system can be flashed in a single command: this writes the boot, recovery and system

partitions together after verifying that the system being flashed is compatible with the installed bootloader

and radio, and reboots the system.

$ fastboot flashall

On all devices except passion, the commands above can be replaced with a single command

$ fastboot -w flashall

Page 21: Initializing a Build Environment

Note that filesystems created via fastboot on Motorola Xoom aren't working optimally, and it is strongly

recommended to re-create them through recovery

$ adb reboot recovery

Once in recovery, open the menu (press Power + Volume Up), wipe the cache partition, then wipe data.

Nexus S and Galaxy Nexus Bootloader and Cell Radio compatibility

On Nexus S, and Galaxy Nexus, each version of Android has only been thoroughly tested with on specific

version of the underlying bootloader and cell radio software. However, no compatibility issues are

expected when running newer systems with older bootloaders and radio images according to the

following tables.

Nexus S (worldwide version "XX", i9020t and i9023):

Android Version Preferred Bootloader

Preferred Radio Also possible

2.3 (GRH55) I9020XXJK1 I9020XXJK8

2.3.1 (GRH78) I9020XXJK1 I9020XXJK8

2.3.2 (GRH78C) I9020XXJK1 I9020XXJK8

2.3.3 (GRI40) I9020XXKA3 I9020XXKB1 All previous versions

2.3.4 (GRJ22) I9020XXKA3 I9020XXKD1 All previous versions

2.3.5 (GRJ90) I9020XXKA3 I9020XXKF1 All previous versions

2.3.6 (GRK39F) I9020XXKA3 I9020XXKF1 All previous versions

4.0.3 (IML74K) I9020XXKL1 I9020XXKI1 All previous versions

4.0.4 (IMM76D) I9020XXKL1 I9020XXKI1

4.0.4 (IMM76I) I9020XXKL1 I9020XXKI1

Page 22: Initializing a Build Environment

Android Version Preferred Bootloader

Preferred Radio Also possible

4.0.4 (IMM76K) I9020XXKL1 I9020XXKI1

4.0.4 (IMM76L) I9020XXKL1 I9020XXKI1

Nexus S (850MHz version "UC", i9020a):

Android Version Preferred Bootloader

Preferred Radio Also possible

2.3.3 (GRI54) I9020XXKA3 I9020UCKB2

2.3.4 (GRJ22) I9020XXKA3 I9020UCKD1 All previous versions

2.3.5 (GRJ90) I9020XXKA3 I9020UCKF1 All previous versions

2.3.6 (GRK39C) I9020XXKA3 I9020UCKF1 All previous versions

2.3.6 (GRK39F) I9020XXKA3 I9020UCKF1 All previous versions

4.0.3 (IML74K) I9020XXKL1 I9020UCKF1 All previous versions

4.0.4 (IMM76D) I9020XXKL1 I9020UCKJ1

4.0.4 (IMM76I) I9020XXKL1 I9020UCKJ1

4.0.4 (IMM76K) I9020XXKL1 I9020UCKJ1

4.0.4 (IMM76L) I9020XXKL1 I9020UCKJ1

Nexus S (Korea version "KR", m200):

Page 23: Initializing a Build Environment

Android Version Preferred Bootloader

Preferred Radio Also possible

2.3.3 (GRI54) I9020XXKA3 I9020KRKB3

2.3.4 (GRJ22) I9020XXKA3 M200KRKC1 All previous versions

2.3.5 (GRJ90) I9020XXKA3 M200KRKC1 All previous versions

2.3.6 (GRK39F) I9020XXKA3 M200KRKC1 All previous versions

4.0.3 (IML74K) I9020XXKL1 M200KRKC1 All previous versions

4.0.4 (IMM76D) I9020XXKL1 M200KRKC1

4.0.4 (IMM76I) I9020XXKL1 M200KRKC1

4.0.4 (IMM76K) I9020XXKL1 M200KRKC1

4.0.4 (IMM76L) I9020XXKL1 M200KRKC1

Galaxy Nexus (GSM/HSPA+):

Android Version Preferred Bootloader

Preferred Radio Also possible

4.0.1 (ITL41D) PRIMEKJ10 I9250XXKK1

4.0.2 (ICL53F) PRIMEKK15 I9250XXKK6 All previous versions

4.0.3 (IML74K) PRIMEKL01 I9250XXKK6 All previous versions

4.0.4 (IMM76D) PRIMEKL03 I9250XXLA02

4.0.4 (IMM76I) PRIMEKL03 I9250XXLA02

4.0.4 (IMM76K) PRIMEKL03 I9250XXLA02

Page 24: Initializing a Build Environment

Android Version Preferred Bootloader

Preferred Radio Also possible

4.0.4 (IMM76L) PRIMEKL03 I9250XXLA02

If you're building a new version of Android, if your Nexus S or Galaxy Nexus has an older bootloader and

radio image that is marked as being also possible in the table above but is not recognized by fastboot,

you can locally delete the version-bootloader and version-baseband lines

in device/samsung/crespo/board-info.txtor device/samsung/maguro/board-info.txt

Restoring a device to its original factory state

Factory images for Galaxy Nexus (GSM/HSPA+ "yakju" and "takju", and CDMA/LTE "mysid") and for

Nexus S (all variants) are available from Google's factory image page.

Factory images for the Motorola Xoom are distributed directly by Motorola.

No factory images are available for Nexus One.

Page 25: Initializing a Build Environment

Building Kernels

If you are only interested in the kernel, you may use this guide to download and build the appropriate

kernel.

The following instructions assume that you have not downloaded all of AOSP. If you have downloaded all

of AOSP, you may skip the git clone steps other than the step to download the actual kernel sources.

We will use the Pandaboard kernel in all the following examples.

Figuring out which kernel to build

You will want to look at the git log for the kernel in the device project that you are interested in. Device

projects are of the form device/<vendor>/<name>.

$ git clone https://android.googlesource.com/device/ti/panda

$ cd panda

$ git log kernel

The log should contain notes of the commit SHA1 for the appropriate kernel project. Keep this value at

hand so that you can use it in a later step.

Downloading sources

Depending on which kernel you want,

Page 26: Initializing a Build Environment

$ git clone https://android.googlesource.com/kernel/common.git

$ git clone https://android.googlesource.com/kernel/exynos.git

$ git clone https://android.googlesource.com/kernel/goldfish.git

$ git clone https://android.googlesource.com/kernel/msm.git

$ git clone https://android.googlesource.com/kernel/omap.git

$ git clone https://android.googlesource.com/kernel/samsung.git

$ git clone https://android.googlesource.com/kernel/tegra.git

The goldfish project contains the kernel sources for the emulated platforms.

The msm project has the sources for ADP1, ADP2, Nexus One, and can be used as a starting

point for work on Qualcomm MSM chipsets.

The omap project is used for PandaBoard and Galaxy Nexus, and can be used as a starting

point for work on TI OMAP chipsets.

The samsung project is used for Nexus S and can be used as a starting point for work on

Samsung Hummingbird chipsets.

The tegra project is for Xoom, and can be used as a starting point for work on NVIDIA Tegra

chipsets.

The exynos project can be used as a starting point for work on Samsung Exynos chipsets.

Downloading a prebuilt gcc

Ensure that the prebuilt toolchain is in your path.

$ git clone https://android.googlesource.com/platform/prebuilt

$ export PATH=$(pwd)/prebuilt/linux-x86/toolchain/arm-eabi-4.4.3/bin:$PATH

Building

As an example, we would build the panda kernel using the following commands:

$ export ARCH=arm

$ export SUBARCH=arm

$ export CROSS_COMPILE=arm-eabi-

$ cd omap

Page 27: Initializing a Build Environment

$ git checkout <commit_from_first_step>

$ make panda_defconfig

$ make

To build the tuna kernel, you may run the previous commands replacing all instances of "panda" with

"tuna".

The kernel for maguro and toro is device/samsung/tuna/kernel

The kernel for crespo and crespo4g is device/samsung/crespo/kernel

The kernel for stingray and wingray is device/moto/wingray/kernel

The image is output as arch/arm/boot/zImage. You may copy it

as device/<vendor>/<name>/kernel or device/ti/panda/kernel in the case of this example.