Android GKI Kernel is a new approach

From Android 11 Google has introduced some improvements in kernel such as the GKI kernel, Bazel build system, etc. But what we’re going to consider is only the Android GKI kernel concept.

What is the Android GKI kernel?

GKI stands for Generic Kernel Image. It consists of 2 parts:

1. Generic kernel
2. GKI modules

The Generic kernel includes all the common parts of the kernel for all devices and variants. But the GKI modules built by Google that are loadable dynamically based on devices. The GKI modules are a type of DLKM (Dynamically Loadable Kernel module) and are signed with the same key as the Generic kernel.

Now with the GKI kernel, SoC and device-specific implementations from vendors and OEMs will be delivered as vendor modules. By AOSP new kernel architecture vendor modules can be updated separately without affecting the GKI kernel. It means that Google has attempted to minimise hardware-specific codes in the GKI kernel and move them out of that. Then vendors and OEMs don’t need to be worried about merging and fixing the conflicts with new versions of the kernel.

The vendor modules required early in the boot should be placed in the vendor_boot partition.

GKI 1.0 was introduced in Android 11 and the beginning of GKI 2.0 was in Android 12.

How does it help?

Before Android 13 there was a sequence for releasing a new kernel. Google combined its patches to Linux LTS kernel known as the Android Common kernel and afterwards, OEM’s and vendor’s patches were added to the Google one. There was a much of pain, especially for OEMs and vendors in that process such as merging and fixing conflicts and refactoring based on the new features or changes.

There are some advantages of the GKI kernel:

1. Updating hardware-specific modules as a part of vendor image
2. Providing security patches easier and faster as a vendor module
3. Adding new functionalities to the kernel as a vendor module
4. Saving time and money for migrating to new kernel versions