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. Figure 1 (below the table) 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).

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

A respin refers to the process of remerging, rebuilding, retesting, and recertifying a binary after a public release of the GKI kernel. You can request a respin of a certified binary for any of the following circumstances:

  • To update a symbol list.
  • To apply a fix to a bug, including bugs found during carrier lab approval.
  • To add a vendor hook.
  • To apply a patch to an existing feature.
  • To apply a security patch (after 6 months).

Security patches are automatically merged into a release branch for up to 6 months after the branch's release. After the 6 month cutoff, you must request a respin to apply security patches to a branch.

Before requesting a respin, note the following guidelines:

  • Respins are allowed only on release branches after an initial public release of a monthly build has been launched.

  • Respin requests are accepted only for a given release branch for a maximum of six months after the initial public release. After six months, branches are eligible for respin only for security patches cited in an Android Security Bulletin.

  • When the LTS requirements cause the branch to be noncompliant, the branch is deprecated. Respin requests for deprecated branches aren't accepted. For example, the 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.

  • Respins are applicable only for urgent bug fixes, symbol list updates, or to apply a patch to fix an existing feature.

  • All patches going into the monthly release branch must already be merged into the main GKI development branch. For example, if a patch is required for a respin of android12-5.10-2022-09, it must already be merged into android12-5.10.

  • You must cherry-pick patches from the main GKI development branch and upload the patch to the monthly release branch.

  • In the respin request, you must assign a priority (urgency) to the request. This priority helps the GKI team to better assist partners in a timely manner. For critical or time-sensitive requests, mark priority as P0. For P0 and P1 requests, you must also justify the urgency. The following table provides a mapping of bug priority and time to resolution (ESRT):

    Priority ESRT
    P0 2 business days
    P1 5 business days
    P2 10 business days
    P3 15 business days
  • You must submit a separate respin request per release branch. For example, if a respin is needed for both android12-5.10-2022-08 and android12-5.10-2022-09, you must create two respin requests.

  • After a build is provided and a respin request is marked as fixed, you shouldn't reopen the respin request to add additional CLs. You must submit a new respin request if there are additional patches that need to be merged.

  • If a respin request requires your response, and you don't respond within three weeks, the request is marked as "Won't Fix (Obsolete)".

Submit a respin request

The following diagram shows the respin process. The process begins when the OEM Partner (you) submits the respin request.

Emergency respin process Figure 2. The respin process

To enter into the respin process:

  1. Fill out the GKI Respin request form. and reach out to your Google Technical Account Manager immediately. This form creates a GKI respin request bug. Respin request bugs are visible to you (the requester), the GKI team, and specific individuals that you add to the bug's CC list.
    • If you already have a fix, the request should point to the patch submittal in AOSP so Google can review it. If submitting the patch isn't feasible, the patch must be attached as a text file to the request.
    • If you don't have a fix, the request must contain as much information as possible, including kernel version number and logs, so Google can help debug the issue.
  2. The Google GKI team reviews the request and approves it or assigns it back to you if more information is needed.
  3. After a fix is agreed upon, the Google GKI team code reviews (CR+2) the change. The review begins the ESRT timeframe. The GKI team merges, builds, tests for regression, and certifies the change.
  4. The binary is released to ci.android.com. The ESRT timeframe ends and the Google GKI team marks the request as fixed and reference the respin build. The respin build is also be posted on the Generic Kernel Image (GKI) release builds page.

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.