Generic Kernel Image (GKI) release process

This page describes how GKI is released, including quarterly and out-of-band emergency releases. The goal of this page 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 GKI development 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 quarterly cadence post KMI freeze.

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 Long-Term Supported (LTS) kernel requirements in the Android Security Bulletin (ASB).

Quarterly certified releases

GKI quarterly 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 quarter, a GKI quarterly release candidate (not certified) is selected after the check-in cutoff date. After the quarterly 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 verify that compliance tests pass on a GSI+GKI build with a reference device as well as Cuttlefish.

Figure 1. GKI release timeline

GKI qualifications

Where to obtain build artifacts

OEMs can obtain artifacts for all the releases from ci.android.com.

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

FAQs

Here are some frequently asked questions related to the GKI release process.

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, here's an example:

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 contain only the patches that are on top of the quarterly 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 quarterly 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 might be different or might be the same.
• The respins on 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 quarterly 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 include only our patch?

This isn't possible. A respin path for individual OEMs isn't 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, or model, the GKI team can verify that the code added by the change executes only on the device, model, or 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 GKI team understands the problem and collects all of the details. You can see this in the changelog (commit message). Google doesn't reveal what specific device it affects, but OEMs can always find the issue description and solution in the changelog.