Generic Kernel Image (GKI) Release Process

This document describes how GKI 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.

Android 13 and 14 GKI Release

The following table is applicable only to android13-5.10, android13-5.15, and android14-6.1.

GKI monthly certified builds Check-in cut off date GKI preload ready date Confirmed?
October October 14, 2022 October 31, 2022 Yes
November November 14, 2022 November 30, 2022 Yes
December December 9, 2022 December 21, 2022 Yes
January January 17, 2023 January 31, 2023 Yes
February February 15, 2023 February 28, 2023 Yes
March March 15, 2023 March 31, 2023 Yes
April April 13, 2023 April 28, 2023 Yes
May May 17, 2023 May 31, 2023 Yes
June June 15, 2023 June 30, 2023 Yes
July July 18, 2023 July 31, 2023 Yes
August August 16, 2023 August 31, 2023 Yes
September September 14, 2023 September 29, 2023 Yes
October October 18, 2023 October 31, 2023 Yes
November November 10, 2023 November 30, 2023 Yes
December December 7, 2023 December 22, 2023 Yes
January January 16, 2024 January 31, 2024 Yes
February February 13, 2024 February 29, 2024 Yes
March March 13, 2024 March 29, 2024 Yes
April April 16, 2024 April 30, 2024 Yes
May May 14, 2024 May 31, 2024 Yes
June June 12, 2024 June 28, 2024 Yes
July July 16, 2024 July 31, 2024 Yes
August August 15, 2024 August 30, 2024 Yes
September September 17, 2024 September 30, 2024 Yes
October October 15, 2024 October 31, 2024 Yes
November November 11, 2024 November 27, 2024 Yes
December December 6, 2024 December 23, 2024 Yes

Starting January 2024, we will resume monthly releases of android14-5.15 in accordance with the specified monthly cadence outlined in the below table.

GKI monthly certified builds Check-in cut off date GKI preload ready date Confirmed?
January January 16, 2024 January 31, 2024 Yes
February February 13, 2024 February 29, 2024 Yes
March March 4, 2024 March 15, 2024 Yes
April April 1, 2024 April 17, 2024 Yes
May May 1, 2024 May 17, 2024 Yes
June June 3, 2024 June 17, 2024 Yes
July July 1, 2024 July 15, 2024 Yes
August August 1, 2024 August 16, 2024 Yes
September September 2, 2024 September 16, 2024 Yes
October October 1, 2024 October 14, 2024 Yes
November November 1, 2024 November 15, 2024 Yes
December December 2, 2024 December 16, 2024 Yes

Android 12 GKI Release

After May 2023, the android12-5.10 GKI releases are on a 2-month cadence and published mid-month. The following table is applicable only to android12-5.10.

GKI monthly certified builds Check-in cut off date GKI preload ready date Confirmed?
July July 3, 2023 July 14, 2023 Yes
September September 1, 2023 September 15, 2023 Yes
November November 3, 2023 November 17, 2023 Yes
January January 5, 2024 January 19, 2024 Yes
March March 4, 2024 March 15, 2024 Yes
May May 1, 2024 May 17, 2024 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 , defined by the Android Security Bulletin (ASB) cause the branch to be noncompliant, the branch is deprecated. Respin requests for deprecated branches aren't accepted. The deprecation date for a given GKI release branch is included in the monthly GKI release build notes under Releases. For future planning, the LTS requirements are updated in May and November annually. For example, the android12-5.10-2023-07 branch (5.10.177) isn't supported for respins after May 1, 2024, because the android12-5.10-2023-07 branch (5.10.177) doesn't comply with the LTS requirements of ASB-2024-05.

  • 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.

  • For each CL under consideration, add the following tags. Progress on the respin request is blocked without this information.

    • Bug: the bug ID must be added to the commit message for each CL.
    • Change-Id: must be identical to the Change-Id of the base branch change.
  • If a respin request requires your response, and you don't respond within three business days, the priority is downgraded by one level (for example, P0 is downgraded to P1). If you don't respond for two weeks, the bug 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.