Generic Kernel Image (GKI) release process

This page 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 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 monthly cadence post KMI freeze.

Android 13, 14, and 15 GKI release

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

The following table is applicable only to android14-6.1 and android15-6.6.

Android 12 GKI release

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

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

GKI binaries are available for self-service from Android CI 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.

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.

Respin request guidelines

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.

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

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

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

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 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 isn't possible. A "per-OEM" respin path 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 ensure that the code added by the change only executes 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 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.