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
$ 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)
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.
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).
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:
$ 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.
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>
$ 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:
$ 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
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.
Building the System
The basic sequence of build commands is as follows:
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
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
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
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.
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
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
$ 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
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
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
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):
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
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.
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,
$ 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
$ 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.