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 Tree

Installing 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_por t>

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 full full_maguro full_panda

Device emulator maguro panda

Notes fully configured with all languages, apps, input methods

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

and the BUILDTYPE is one of the following:

Buildtype user userdebug eng

Use limited access; suited for production like "user" but with root access and debuggability; preferred for debugging 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 Errors

Wrong 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 OpenSource 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 maguro panda wingray crespo passion sapphire

Keys Press and hold both Volume Up and Volume Down, then press and hold Power Press and hold Input, then press Power Press and hold Volume Down, then press and hold Power Press and hold Volume Up, then press and hold Power Press and hold the trackball, then press Power Press and hold Back, then press Power

Device dream

Keys 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 maguro panda wingray crespo passion sapphire

Branch android-4.0.4_r2.1 or master master android-4.0.4_r2.1 or master android-4.0.4_r2.1 or master android-2.3.7_r1 android-2.2.3_r1

Build configuration full_maguro-userdebug full_panda-userdebug full_wingray-userdebug full_crespo-userdebug full_passion-userdebug full_sapphire-userdebug

Device dream

Branch android-2.2.3_r1

Build configuration 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 2.3 (GRH55) 2.3.1 (GRH78) 2.3.2 (GRH78C) 2.3.3 (GRI40) 2.3.4 (GRJ22) 2.3.5 (GRJ90) 2.3.6 (GRK39F) 4.0.3 (IML74K) 4.0.4 (IMM76D) 4.0.4 (IMM76I) 4.0.4 (IMM76K) 4.0.4 (IMM76L)

Preferred Bootloader I9020XXJK1 I9020XXJK1 I9020XXJK1 I9020XXKA3 I9020XXKA3 I9020XXKA3 I9020XXKA3 I9020XXKL1 I9020XXKL1 I9020XXKL1 I9020XXKL1 I9020XXKL1

Preferred Radio I9020XXJK8 I9020XXJK8 I9020XXJK8 I9020XXKB1 I9020XXKD1 I9020XXKF1 I9020XXKF1 I9020XXKI1 I9020XXKI1 I9020XXKI1 I9020XXKI1 I9020XXKI1

Also possible

All previous versions All previous versions All previous versions All previous versions All previous versions

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

Android Version 2.3.3 (GRI54) 2.3.4 (GRJ22) 2.3.5 (GRJ90) 2.3.6 (GRK39C)

Preferred Bootloader I9020XXKA3 I9020XXKA3 I9020XXKA3 I9020XXKA3

Preferred Radio I9020UCKB2 I9020UCKD1 I9020UCKF1 I9020UCKF1

Also possible

All previous versions All previous versions All previous versions

Android Version 2.3.6 (GRK39F) 4.0.3 (IML74K) 4.0.4 (IMM76D) 4.0.4 (IMM76I) 4.0.4 (IMM76K) 4.0.4 (IMM76L)

Preferred Bootloader I9020XXKA3 I9020XXKL1 I9020XXKL1 I9020XXKL1 I9020XXKL1 I9020XXKL1

Preferred Radio I9020UCKF1 I9020UCKF1 I9020UCKJ1 I9020UCKJ1 I9020UCKJ1 I9020UCKJ1

Also possible All previous versions All previous versions

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

Android Version 2.3.3 (GRI54) 2.3.4 (GRJ22) 2.3.5 (GRJ90) 2.3.6 (GRK39F) 4.0.3 (IML74K) 4.0.4 (IMM76D) 4.0.4 (IMM76I) 4.0.4 (IMM76K) 4.0.4 (IMM76L)

Preferred Bootloader I9020XXKA3 I9020XXKA3 I9020XXKA3 I9020XXKA3 I9020XXKL1 I9020XXKL1 I9020XXKL1 I9020XXKL1 I9020XXKL1

Preferred Radio I9020KRKB3 M200KRKC1 M200KRKC1 M200KRKC1 M200KRKC1 M200KRKC1 M200KRKC1 M200KRKC1 M200KRKC1

Also possible

All previous versions All previous versions All previous versions All previous versions

Galaxy Nexus (GSM/HSPA+):

Android Version 4.0.1 (ITL41D) 4.0.2 (ICL53F) 4.0.3 (IML74K) 4.0.4 (IMM76D) 4.0.4 (IMM76I) 4.0.4 (IMM76K) 4.0.4 (IMM76L)

Preferred Bootloader PRIMEKJ10 PRIMEKK15 PRIMEKL01 PRIMEKL03 PRIMEKL03 PRIMEKL03 PRIMEKL03

Preferred Radio I9250XXKK1 I9250XXKK6 I9250XXKK6 I9250XXLA02 I9250XXLA02 I9250XXLA02 I9250XXLA02

Also possible

All previous versions All previous versions

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.