Establishing a Build Environment

This section describes how to set up your local work environment to build the Android source files. You must use Linux or Mac OS; building under Windows is not currently supported.

For an overview of the entire code-review and code-update process, see Life of a Patch.

Choosing a branch

Some requirements for the build environment are determined by the version of the source code you plan to compile. For a full list of available branches, see Build Numbers. You can 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.

After 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 (14.04) and Debian testing. Most other distributions should have the required build tools available.

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.

Installing required packages (Ubuntu 14.04)

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

sudo apt-get install git-core gnupg flex bison gperf build-essential zip curl zlib1g-dev gcc-multilib g++-multilib libc6-dev-i386 lib32ncurses5-dev x11proto-core-dev libx11-dev lib32z-dev libgl1-mesa-dev libxml2-utils xsltproc unzip

Installing required packages (Ubuntu 12.04)

You may use Ubuntu 12.04 to build older versions of Android. Version 12.04 is not supported on master or recent releases.

sudo apt-get install git gnupg flex bison gperf build-essential zip curl libc6-dev libncurses5-dev:i386 x11proto-core-dev libx11-dev:i386 libreadline6-dev:i386 libgl1-mesa-glx:i386 libgl1-mesa-dev g++-multilib mingw32 tofrodos python-markdown libxml2-utils xsltproc zlib1g-dev:i386
sudo ln -s /usr/lib/i386-linux-gnu/mesa/libGL.so.1 /usr/lib/i386-linux-gnu/libGL.so

Installing required packages (Ubuntu 10.04 -- 11.10)

Building on Ubuntu 10.04-11.10 is no longer supported, but may be useful for building older releases of AOSP.

sudo apt-get install git 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

On Ubuntu 10.10:

sudo ln -s /usr/lib32/mesa/libGL.so.1 /usr/lib32/mesa/libGL.so

On Ubuntu 11.10:

sudo apt-get install libx11-dev:i386

Configuring USB access

Install a community-maintained default set of udev rules for all Android devices by following the instructions to Set up a device for development.

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 Jelly Bean (4.1) and newer, including the master branch.

Setting up a Mac OS build environment

In a default installation, Mac OS runs on a case-preserving but case-insensitive filesystem. This type of filesystem is not supported by git and will cause some git commands (such as git status) to behave abnormally. Because of this, we recommend that you always work with the AOSP source files on a case-sensitive filesystem. This can be done fairly easily using a disk image, discussed below.

Once the proper filesystem is available, building the master branch in a modern Mac OS environment is very straightforward. Earlier branches require some additional tools and SDKs.

Creating a case-sensitive disk image

You can create a case-sensitive filesystem within your existing Mac OS environment using a disk image. To create the image, launch Disk Utility and select New Image. A size of 25GB is the minimum to complete the build; larger numbers are more future-proof. Using sparse images saves space while allowing to grow later as the need arises. Be sure to select case sensitive, journaled as the volume format.

You can also create it from a shell with the following command:

hdiutil create -type SPARSE -fs 'Case-sensitive Journaled HFS+' -size 40g ~/android.dmg

This will create a .dmg (or possibly a .dmg.sparseimage) file which, once mounted, acts as a drive with the required formatting for Android development.

If you need a larger volume later, you can also resize the sparse image with the following command:

hdiutil resize -size <new-size-you-want>g ~/android.dmg.sparseimage

For a disk image named android.dmg stored in your home directory, you can add helper functions to your ~/.bash_profile:

  • To mount the image when you execute mountAndroid:
        # mount the android file image
        mountAndroid() { hdiutil attach ~/android.dmg -mountpoint /Volumes/android; }
  • To unmount it when you execute umountAndroid:
         # unmount the android file image
         umountAndroid() { hdiutil detach /Volumes/android; }

After you've mounted the android volume, you'll do all your work there. You can eject it (unmount it) just as you would an external drive.

Installing Xcode and other packages

  1. Install Xcode command line tools with:
        xcode-select --install
    For older versions of Mac OS (10.8 or earlier), you must install Xcode from the Apple developer site. If you are not already registered as an Apple developer, you must create an Apple ID to download.
  2. Install either MacPorts or Homebrew for package management.
  3. Ensure the associated directory is in your path within your ~/.bash_profile file:
    1. MacPorts - /opt/local/bin must appear before /usr/bin:
              export PATH=/opt/local/bin:$PATH
    2. Homebrew - /usr/local/bin:
              export PATH=/usr/local/bin:$PATH
    3. For MacPorts, issue:
          POSIXLY_CORRECT=1 sudo port install git gnupg
    4. For Homebrew, issue:
          brew install git gnupg2

    Setting a file descriptor limit

    On Mac OS, the default limit on the number of simultaneous file descriptors open is too low and a highly parallel build process may exceed this limit. To increase the cap, add the following lines to your ~/.bash_profile:

    # set the number of open files to be 1024
    ulimit -S -n 1024

    Next: Download the source

    Your build environment is good to go! Proceed to downloading the source.