Generic Kernel Image (GKI) Release Process

This document describes how GKI v5.10 for Android 12 is released, including weekly, monthly, and out of band emergency releases. The goal of this document is to give OEMs a guideline on where to pick up the GKI as well as the process for out of band emergency fixes. OEMs can also use the GKI Development guide to learn more about how they can work with the Android Kernel team to optimize the GKI kernel for their products.

GKI release cadence

GKI is released on a monthly cadence post KMI Freeze starting July 14, 2021. The following graphic illustrates the cadence of the release schedule.

GKI Monthly Certified Builds Check-In cut off date GKI Preload Ready date Label Confirmed?
July
(KMI Freeze)
July 14, 2021 End of July Android 12
AOSP Certified Build - July
Yes
August August 16, 2021 End of August Android 12
AOSP Certified Build - August
Yes
September September 17, 2021 End of September Android 12
AOSP Certified Build - September
Yes
October October 15, 2021 October 29, 2021 Android 12
AOSP Certified Build - October
Yes
November November 12, 2021 November 30, 2021 Android 12
AOSP Certified Build - November
Yes
December December 10, 2021 December 22, 2021 Android 12
AOSP Certified Build - December
Yes
January January 14, 2022 January 31, 2022 Android 12
AOSP Certified Build - January
Yes
February February 14, 2022 February 28, 2022 Android 12
AOSP Certified Build - February
Yes
March March 16, 2022 March 31, 2022 Android 12
AOSP Certified Build - March
Yes
April April 15, 2022 April 29, 2022 Android 12
AOSP Certified Build - April
Yes
May May 16, 2022 May 31, 2022 Android 12
AOSP Certified Build - May
Yes
June June 15, 2022 June 30, 2022 Android 12
AOSP Certified Build - June
Yes
July July 15, 2022 July 29, 2022 Android 12
AOSP Certified Build - July
Yes
August August 15, 2022 August 31, 2022 Android 12
AOSP Certified Build - August
Yes
September September 16, 2022 September 30, 2022 Android 12
AOSP Certified Build - September
Yes
October October 14, 2022 October 31, 2022 Android 12
AOSP Certified Build - October
Yes
November November 14, 2022 November 30, 2022 Android 12
AOSP Certified Build - November
Yes
December December 9, 2022 December 21, 2022 Android 12
AOSP Certified Build - December
Yes

GKI build validity for OEMs

OEMs can use a recently released Android GKI. OEMs can launch with GKI-certified builds as long as they are compliant with LTS requirements in the Android Security Bulletin (ASB).

Certified build respin policy

  • GKI certified binaries aren't supported for respins after they are no longer compliant with the LTS requirements in the ASB. For example, android12-5.10-2021-11 branch (5.10.66) isn't supported for respins after November 2022, because the android12-5.10-2021-11 branch (5.10.66) doesn't comply with the LTS requirements of ASB-2022-11.
  • See Emergency respin process for further information.

Weekly development releases

Releases are tested with cuttlefish to ensure they pass a minimum quality bar.

GKI binaries are available for self-service from ci.android.com as changes are merged. Weekly builds won't be certified, though can be used as a baseline for development and testing. Weekly builds can't be used for production device builds for end users.

Monthly certified releases

GKI monthly releases contain a tested boot.img that includes a Google inserted certificate to attest that the binaries were built from a known source code baseline.

Each month, a GKI monthly release candidate (not certified) is selected after the check-in cut off date, which is usually the second weekly build of that month. After the monthly release candidate is selected, new changes won't be accepted into that month’s release. During the closed window period, only fixes for bugs that cause test failure can be addressed. The release candidate undergoes quality assurance—as described in the GKI qualification section—to ensure compliance tests pass on GSI+GKI build with a reference device as well as cuttlefish.

GKI release cadence timeline Figure 1. GKI release timeline

Emergency respin process

Emergency respin process Figure 2. The emergency respin process

OEMs might need to respin the kernel for Technical Approvals (TA) that are blocking the issue. Respins are supported on monthly certified release builds, and have an expected standard resolution time (ESRT) of two business days in the US timezone.

ESRT is defined as the time it takes to deliver a certified GKI binary that contains the fix, so long as it's been approved by the GKI team and reviewed by the affected OEM. ESRT is an estimate only and shouldn't be interpreted as a guarantee.

OEMs who need a respin for a TA blocking fix need to do the following:

  1. File a bug in the Issue Tracker and reach out to your Google point of contact immediately.
    • If you already have a fix, the bug should point to the patch submittal in AOSP so Google can review it. If submitting the patch isn't feasible, attach the patch as a text file to the bug in the Issue Tracker.
    • If you don't have a fix yet, the bug must include as much information as possible, including kernel version number and logs, so Google can help debug the issue.
  2. After a fix is agreed upon, the Google GKI team code reviews (CR+2) the change and tests for regression. Testing starts the ESRT countdown, and ends when the binary is published to ci.android.com.

GKI qualifications

Types of GKI builds Quality enforcement Notes
Weekly Cuttlefish testing
  • Boot
  • Subset of VTS
  • Subset of CTS
  • Not certified. Only for testing and
    device bring up.
  • Can't be used for launching devices.
Monthly (certified) Cuttlefish testing
  • Boot
  • VTS
  • CTS
Reference hardware testing
  • Boot
  • VTS
  • CTS
Respins (certified) Cuttlefish testing
  • Boot
  • VTS
  • Subset of CTS
Reference device testing
  • Boot
  • VTS
  • Built on top of a GKI certified build.
  • The build is certified after qualification.

Where to obtain build artifacts

Artifacts for all the releases can be obtained from ci.android.com.

You can find more information on the CI, including the test results on the Android Continuous Integration dashboard.

FAQs

Is it possible to build a new GKI binary based on an already released GKI?

Yes, this is known as a respin. The respin process is supported as long as the released GKI build (on which the respin is requested) is compliant with LTS requirements in the Android Security Bulletin (ASB).

Is it possible to reproduce GKI binaries?

Yes, reference the example below.

GKI 2.0
5.10 kernel prebuilts from build 7364300
https://ci.android.com/builds/submitted/7364300/kernel_aarch64/latest

To reproduce the example, download manifest_$id.xml and execute the following command:

repo init -u https://android.googlesource.com/kernel/manifest
mv manifest_7364300.xml .repo/manifests
repo init -m manifest_7364300.xml --depth=1
repo sync
# build the GKI images
# You may want to use LTO=thin to build faster for development
BUILD_CONFIG=common/build.config.gki.aarch64 build/build.sh
# (optional) build virtual platform modules
BUILD_CONFIG=common-modules/virtual-device/build.config.virtual_device.aarch64 build/build.sh

You can retrieve your GKI artifact copy from out/.../dist.

Has the GKI binary (including the emergency spin patch) been built on the

latest codebase?

No. Respins only contain patches that are on top of the monthly certified kernels that have been chosen. These respins contain all launch blocking bug fixes reported until any given time by OEMs using the corresponding base monthly release. See the following example of how this type of scenario happens.

  • OEM1 and OEM2 decide to use the GKI binary release from November 2021.
  • OEM1 and OEM2 find issues that require patches for support. These patches may be different or may be the same.
  • The respins over top of the November 2021 binary have launch blocking fixes reported by both OEM1 and OEM2 during the respin window, but nothing more.
  • The issues mentioned in the second bullet are also included in subsequent GKI monthly releases.

The October respin has all OEM submitted patches, but other OEM patches

affect us, because they haven't been specifically tested with our products. Is it possible to only include our patch?

This is not possible. A "per-OEM" respin path is currently not scalable. Instead, the GKI team scrutinizes every single change that goes into respin builds, and tests the changes with all available hardware before creating a new build. If the GKI team finds that the issue is specific to an OEM/device/model, the GKI team can ensure that the code added by the change only executes on the device/model/SKU being affected.

The major benefit from unified respins is that every device that's using the same release base benefits from one another, especially if the bugs they discover are generic and applicable to all users. Core kernel bugs found in carrier testing is a specific example of this concept.

Are there situations where Google provides specific information about OEM patches and issue scenarios, so that OEMs can evaluate the impact and risk of implementing the patches with their products?

Google won't ever add a change to a respin build until the problem is understood and all of the details have been collected. This is seen in the changelog (commit message). Google does not reveal what specific device it affects, but OEMs can always find the issue description and solution in the changelog.