Codenames, Tags, and Build Numbers

Android development happens around families of releases that use code names ordered alphabetically after tasty treats.

Platform Codenames, Versions, API Levels, and NDK Releases

The code names match the following version numbers, along with API levels and NDK releases provided for convenience:

In Android 8.0 (Oreo) and higher, individual builds are identified with the build ID format PVBB.YYMMDD.bbb[.Cn], where:

• P represents the first letter of the code name of the platform release, e.g. O is Oreo.
• V represents a supported vertical. By convention, P represents the primary platform branch.
• BB represents an alphanumeric code that allows Google to identify the exact code branch the build was made from.
• YYMMDD identifies the date when the release is branched from or synced with the development branch. It is not guaranteed to be the exact date at which a build was made as it is common for minor variations added to an existing build to re-use the same date code as the existing build.
• bbb identifies individual versions related to the same date code, sequentially starting with 001.
• Cn is an optional, alphanumeric that identifies a hotfix on top of an existing PVBB.YYMMDD.bbb build, starting from A1.

Older Android releases use a different, shorter build ID code (e.g. FRF85B) where:

• The first letter is the code name of the release family, e.g. F is Froyo.
• The second letter is a branch code that allows Google to identify the exact code branch the build was made from. By convention, R is the primary release branch.
• The third letter and following two digits are a date code. The letter counts quarters (A = Q1 2009, F = Q2 2010, etc.). The two digits count days within the quarter (F85 is June 24 2010). The date code is not guaranteed to be the exact date at which a build was made as it is common for minor variations added to an existing build to re-use the same date code as the existing build.
• The last letter identifies individual versions related to the same date code, sequentially starting with A (which is implicit and usually omitted for brevity.

Source Code Tags and Builds

Starting with Donut, the exact list of tags and builds is in the following table.

The branches froyo, gingerbread, ics-mr0, ics-mr1, jb-dev, jb-mr1-dev, jb-mr1.1-dev, jb-mr2-dev, kitkat-dev represent development branches that do not exactly match configurations tested by Google. As such, these branches might contain a variety of changes in addition to the official tagged releases and might not be as thoroughly tested.

To differentiate between releases, you can obtain a list of changes associated with each project by issuing the following command and passing it the two branch tags:

repo forall -pc 'git log --no-merges --oneline branch-1..branch-2'

For example:

repo forall -pc 'git log --no-merges --oneline android-4.4.2_r2..android-4.4.2_r1'

To send the output to a text file:

  repo forall -pc 'git log --no-merges --oneline android-4.4.2_r2..android-4.4.2_r1' > /tmp/android-4.4.2_r2-android-4.4.2_r1-diff.txt

Honeycomb GPL Modules

For Honeycomb, the entire platform source code isn't available. However, the parts of Honeycomb licensed under the GPL and LGPL are available under the following tags:

While no manifest contains exactly these modules, some manifests allow building those components. The following commands work for 3.0_r1.1:

repo init -b master -m base-for-3.0-gpl.xml
repo sync
repo forall -c git checkout android-3.0_r1.1

To use another version, switch the git checkout parameter and (if necessary) the -m parameter in repo init. The git checkout command outputs an error for the non-GPL projects, where it can't find the tag in question.