A product kernel, also known as a device kernel or OEM kernel, is the kernel that you ship on your device. Prior to GKI, the product kernel was derived from a series of upstream kernel changes. Figure 1 shows how kernel additions yield a product kernel (OEM/device kernel):
Figure 1. Pre-GKI product kernel construction.
- The Linux Long Term Supported (LTS) kernel from kernel.org was modified with Android-specific patches resulting in an Android Common Kernel (ACK).
- The ACK was modified by vendors who added support for their system-on-a-chip (SoC). The vendors might also add performance or power optimizations. The resulting kernel is called the vendor kernel.
- Finally, the vendor kernel was further modified by OEMs with additional device drivers and customizations they deem necessary. The resulting kernel is called the product kernel.
All of these modifications can result in as much as 50% of kernel code being out-of-tree code and not from upstream Linux kernels or ACKs. Prior to GKI, nearly every device had a custom kernel that resulted in kernel fragmentation.
Costs of fragmentation
Kernel fragmentation has several negative effects on the Android community.
Security updates are labor intensive
Security patches cited in the Android Security Bulletin (ASB) must be backported into each of the device kernels. However, due to kernel fragmentation, it's prohibitively expensive to propagate security fixes to Android devices in the field.
Difficult to merge Long-Term Supported updates
The Long-Term Supported (LTS) releases include security fixes and other critical bug fixes. Staying up to date with LTS releases has proven to be the most effective way to provide security fixes. On Pixel devices, it was discovered that 90% of the kernel security issues reported in the ASB had already been fixed for devices that stay up to date.
However, with all of the custom modifications in the device kernels, it's difficult to just merge the LTS fixes into device kernels.
Inhibit Android platform release upgrades
Fragmentation makes it difficult for new Android features requiring kernel changes to be added to devices in the field. Android Framework code must assume that as many as five kernel versions are supported and that no kernel changes were made for the new platform release (Android 10 supports 3.18, 4.4, 4.9, 4.14, and 4.19 kernels, which in some cases haven't been enhanced with new features since Android 8 in 2017).
Difficult to contribute kernel changes back to upstream Linux
With all of the changes being made to the kernel, most flagship devices ship
with a kernel version that's already at least 18 months old. For example, the
4.14 kernel was released by
kernel.org in November of 2017 and the
first Android phones using 4.14 kernels shipped in the spring of 2019.
This long delay between upstream kernel release and products makes it difficult for the Android community to feed needed features and drivers into the upstream kernels.
Fix the fragmentation: Generic Kernel Image
The Generic Kernel Image (GKI) project addresses kernel fragmentation by unifying the core kernel and moving SoC and board support out of the core kernel into loadable vendor modules. GKI also presents a stable Kernel Module Interface (KMI) for vendor modules, so modules and kernel can be updated independently. Some characteristics of the GKI kernel are:
- The GKI kernel is built from the ACK sources.
- The GKI kernel is a single-kernel binary plus associated loadable modules
per architecture, per LTS release (currently only arm64 for
android11-5.4andandroid12-5.4). - The GKI kernel is tested with all Android Platform releases that are supported for the associated ACK. There's no feature deprecation for the lifetime of a GKI kernel version.
- The GKI kernel exposes a stable KMI to drivers within a given LTS.
- The GKI kernel doesn't contain SoC-specific or board-specific code.
For an image of GKI architecture, refer to the Kernel overview.
GKI is a complex change that rolled out in several stages starting with the v5.4 kernels in the Android 11 platform release.
There are two GKI stages:
- GKI 1.0 was introduced in Android 11 for devices with 5.4 kernels. GKI 1.0 applies to all devices shipped with 5.4 kernels, even those launched with Android 12 or Android 13.
- GKI 2.0 was introduced in Android 12 for devices with 5.10 kernels and is the new standard for all devices that ship with 5.10 or later kernels.
GKI 1.0
In GKI 1.0, devices launching with kernel version 5.4 must pass GKI testing (Android 11 and later platform releases). GKI 1.0 goals include the following:
- Avoid regressions in Vendor Test Suite (VTS) or Compatibility Test Suite (CTS) when replacing the product kernel with the GKI kernel.
- Reduce the partner burden of keeping their kernel up to date with AOSP common kernels.
- Include core Android changes in kernels for devices upgrading and launching with new Android releases.
- Don't break Android userspace.
- Separate hardware-specific components from the core kernel as loadable modules.
For GKI 1.0 documentation, see the GKI 1.0 section.
GKI 2.0
In GKI 2.0, devices launching with kernel version 5.10 or higher must ship with the GKI kernel (beginning with Android 12). Signed boot images are available and updated regularly with LTS and critical bug fixes. Because binary stability is maintained for the KMI, you can install these boot images without making changes to vendor images. GKI 2.0 goals include the following:
- Don't introduce significant performance or power regressions when replacing the product kernel with the GKI kernel.
- Enable partners to deliver kernel security fixes and bug fixes without vendor involvement.
- Reduce the cost of updating the major kernel version for devices (for example, from v5.10 to the 2021 LTS kernel).
- Maintain a single GKI kernel binary per architecture by updating kernel versions with a clear process for upgrading.
GKI 2.0 represents the most current state of Android kernels. Kernel documentation outside the GKI 1.0 and Previous kernels (<=4.19) subsections reflect GKI 2.0 architecture.