Overview

The Android team follows a specific release methodology, only release builds that boot to a full Android UI. If a build doesn't boot up to a full UI we don't release it. At this point this is our minimum standard.

This philosophy means that any build you release has been at boot tested first.

What do I "Release" when I make an Android Build

An Android build is defined by a manifest. An Android manifest is an XML file that lists gits. The branch may be specified or not or a specific commit can be specified. These gits can be located anywhere. Because gits can be located anywhere there is no way to lay a "tag" across all of them.

At this point its worth looking at an example.

Go to http://android-build.linaro.org and click on a tip build. A tip build does not have a -YR.MN-release. The build will have two files listed down the page a bit, a source-manifest.xml and a pinned-manifest.xml. The source-manifest.xml comes from the manifest you're building. The pinned-manifest.xml file is generated from the build. After all the gits are synced, the build system looks at the heads of all the gits and notes the commit-ids of the heads. If you don't understand what this means, take a look at how git works. To get you going, git records the entire history of a tree as a set of commits. These commits are identified by a 40 character SHA1 hash. The last commit's SHA1 constitutes the latest and greatest state of that tree. If you know it, you can check the tree out in exactly the same state. So the pinned-manifest.xml collects all the SHA1's of all the git heads.

You can create a build from the source-manifest.xml or the pinned-manifest.xml. If you use the source-manifest.xml you'll get the heads of all the gits if you use the pinned-manifest.xml you'll get the gits at exactly the commits that were listed.

When you "release a build" you are really just releasing a pinned-manifest.xml.

Release Cadence

We release a preview release each week and a final release the last Monday of the cycle. The preview releases are entered into the testing spreadsheets and basic smoketests are run on them. The final release is entered into the spreadsheet and all tests are run on it. See the builds for a link to the test spreadsheets.

Testing

Testers should start with the tests that are failing and verify that the test is no longer failing. If the test is no longer failing the user should update the bug with the build URL tested (like https://android-build.linaro.org/builds/~linaro-android/tracking-panda/#build=139) and mark the bug "Fix Released." If the test still fails the bug should be updated with the build URL and any additional information should be added to the bug.

How to Create a Release

In general the process is:

  1. Select a the tip you want to release.
  2. Boot test it.
  3. Clone the manifest git.
  4. Save the pinned-manifest.xml from the build you tested over the manifest the build was built from, preserving the original name.
  5. Commit the change and push to Gerrit for review on the release branch.
  6. Once reviewed, create a release build or rebuild an existing release build (the change is now committed so it'll be picked up).

The rest of this review expands on these steps.

How to Create the First Preview Release Candidate

If you're creating the first preview RC, you'll need a release branch.

To create the branch, log into Gerrit at http://review.android.git.linaro.org. You must be part of the project's Owner group to create and delete a branch which is set to Administrators.

To create the preview and final releases

Click on Admin > Projects
Click on platform/manifest
Click on Branches

Enter:

Branch Name: linaro-android-12.01-release (12.01 should match the release cycle)
Initial Revision: linaro_android_4.0.3 (this should match whatever branch the current builds are on, all builds should be on the same branch)

Click the 'Create Branch' button

On the command line clone the manifest

git clone git://android.git.linaro.org/platform/manifest.git

cd manifest

If you've already cloned you can just

git fetch

Checkout the branch

git checkout linaro-android-12.01-release

To create a new branch from the command line do:

git clone git://android.git.linaro.org/platform/manifest git checkout -b linaro-android-12.01-release linaro_android_4.0.3

Note: linaro-android-12.01-release and linaro_android_4.0.3 are only examples.

After checking out the branch you should see a list of xml files. Make a list of all the builds that work:

https://android-build.linaro.org/builds/~linaro-android/tracking-panda/#build=139
https://android-build.linaro.org/builds/~linaro-android/staging-imx53/#build=142
https://android-build.linaro.org/builds/~linaro-android/landing-panda/#build=15
https://android-build.linaro.org/builds/~linaro-android/landing-snowball/#build=113
https://android-build.linaro.org/builds/~linaro-android/staging-panda/#build=184
https://android-build.linaro.org/builds/~linaro-android/staging-snowball/#build=154
https://android-build.linaro.org/builds/~linaro-android/staging-vexpress-a9/#build=47
https://android-build.linaro.org/builds/~linaro-android/panda/#build=463
https://android-build.linaro.org/builds/~linaro-android/staging-origen/#build=130

You now need to save the pinned manifests. As some builds have their own manifest file and some use a common manifest you will need to create some new files. You can tell if a build has its own manifest file by looking at the MANIFEST_FILENAME parameter in the build configuration. Visit each build page and save the pinned-manifest.xml from each build. If it has a dedicated manifest file simply save over it. If you need to create a new xml file the convention is to name the xml file the name of the build, staging-iMX53.xml violates this, but that's okay. Also. If you look at the panda build you won't see the manifest file called out. That's okay. android-build uses the default.xml file if none is called out, just save the pinned-manifest.xml from panda as default.xml. The pinned-manifest.xml from any build that doesn't explicitly call out a manifest can be used as default.xml. If you are unsure what to name it you can look at the preceding release and check what it was named there.

To commit this do:

1. git add <each.xml>

2. git commit

3. When the window pops up use test like the following:

    manifest: (All) first 12.02 release (RC)
    
    pinned-manifest.xml from:
    
    https://android-build.linaro.org/builds/~linaro-android/panda-ics-gcc46-kwg-upstream-open/#build=508, default.xml
    https://android-build.linaro.org/builds/~linaro-android/panda-ics-gcc46-omapzoom-stable-blob/#build=67, landing-panda.xml
    https://android-build.linaro.org/builds/~linaro-android/snowball-ics-gcc46-igloo-stable-blob/#build=168, landing-snowball.xml
    https://android-build.linaro.org/builds/~linaro-android/imx53-ics-gcc46-freescalelt-stable-open/#build=191, staging-iMX53.xml
    https://android-build.linaro.org/builds/~linaro-android/imx6-ics-gcc46-freescalelt-stable-open/#build=3, staging-iMX6.xml
    https://android-build.linaro.org/builds/~linaro-android/origen-ics-gcc46-samsunglt-stable-blob/#build=187, staging-origen.xml
    https://android-build.linaro.org/builds/~linaro-android/vexpress-ics-gcc46-armlt-stable-open/#build=96, staging-vexpress-a9.xml
    https://android-build.linaro.org/builds/~linaro-android/panda-ics-gcc46-tilt-tracking-blob/#build=188, tracking-panda.xml
    
    Signed-off-by: Firstname Lastname <firstname.lastname@linaro.org>

4. Then:

git push ssh://firstname.lastname@android.git.linaro.org:29418/platform/manifest HEAD:refs/for/linaro-android-12.03-release

Open the link obtained after the git push (looks like: http://review.android.git.linaro.org/<change-id>

Add Vishal Bhoj for reviewing and merging this change

If for some reason the commit message is not correct please do a "git commit --amend" to correct the commit message, also add the Line "Change-Id: <change-id obtained from above review link>" just above the line Signed-off-by: Firstname Lastname <firstname.lastname@linaro.org> in your commit message. (This is done to update same change-id with patchset-2 instead of getting a new change-id) Now do a git push using the same push commands as earlier. (Note: This has to be done only in the case if your change was not verified/approved in first submission")

Once the change is approved and merged follow instructions given below:

Copy the build configuration from the mainline you're going to release. This is listed on the build itself. For instance:

https://android-build.linaro.org/builds/~linaro-android/landing-panda/#build=15

uses:

MANIFEST_REPO=git://android.git.linaro.org/platform/manifest.git
MANIFEST_BRANCH=linaro_android_4.0.3
MANIFEST_FILENAME=landing-panda.xml
TARGET_PRODUCT=pandaboard
TARGET_SIMULATOR=false
TOOLCHAIN_URL=http://android-build.linaro.org/builds/~linaro-android/toolchain-4.6-2011.12/5/android-toolchain-eabi-linaro-4.6-2011.12-5-2011-12-12_14-40-40-linux-x86.tar.bz2
TOOLCHAIN_TRIPLET=arm-linux-androideabi
REPO_SEED_URL=http://android-build.linaro.org/seed/pandaboard.mirror.tar.gz
LAVA_SUBMIT_FATAL=0

If TOOLCHAIN_URL points to tip toolchain, i.e if it looks like

TOOLCHAIN_URL=http://android-build.linaro.org/download/linaro-android_toolchain-4.6-bzr/lastSuccessful/archive/build/out/android-toolchain-eabi-4.6-daily-linux-x86.tar.bz2

Then the exact toolchain used to build that specific release needs to be found out, this can be done as following:

  1. From build's frontend page (should be always a starting point for any info), click "Log" -> "Tail" to go to build's Jenkins page.

  2. Click "See Fingerprints" in the left nav column.
  3. In the "Original owner" column, behold the toolchain build link.
  4. If there's no link, it means that toolchain build wasn't fingerprinted, please rebuild toolchain.
  5. If there's no fingerprinting entry at all, it means that upstream binary toolchain was used.

Check for example

https://android-build.linaro.org/builds/~linaro-android/imx6-ics-gcc47-freescalelt-stable-open/#build=35

Finally TOOLCHAIN_URL should look like this: (snapshot image should be used)

e.g. TOOLCHAIN_URL=http://snapshots.linaro.org/android/~linaro-android/toolchain-4.6-bzr/234/android-toolchain-eabi-4.6-daily-linux-x86.tar.bz2

Go back to https://android-build.linaro.org/ and click on New Build...

Select linaro-android in the Name combo box to create an official build

Copy the build configuration into the text box.

Name the build following the naming convention: ${build}-${version}-release. e.g. landing-snowball-12.01-release

Update the MANIFEST_BRANCH to match the branch you created above. e.g. MANIFEST_BRANCH=linaro-android-12.01-release

Click on save & build button.

Once the build is completed, update the test spreadsheet for the given board:

As mentioned above, this should be done weekly. What seems to work best is:

  1. do a preview release and test everything
  2. then switch the builds to the tip toolchain
  3. once the toolchain is released, switch the builds to it, test and do a release
  4. then do a final release at the end of the cycle

Platform/Android/CreateARelease (last modified 2013-10-09 07:02:04)