Some GKI kernel functionality is delivered in modules to reduce the GKI kernel memory footprint on devices that don't require the functionality. This architecture also provides a mechanism to allow vendors to incorporate new upstream features after the KMI freeze milestone. GKI modules are signed by Google using the kernel build time key pair and are compatible only with GKI they are built with. There is no ABI stability between the GKI kernel and GKI modules, so the kernel and GKI modules must be built and updated together for modules to load correctly during runtime.
There are two logical types of GKI modules: protected GKI module and unprotected GKI module.
Protected GKI module
A protected GKI module is delivered by Google, isn't restricted in any way, and behaves as though it is built with the kernel after loading. Additionally, protected GKI modules have the following characteristics:
- Protected GKI modules have access to non-KMI kernel symbols that aren't available to vendor modules or unprotected GKI modules.
- Protected GKI modules can export symbols that become part of the KMI surface as long as those symbols are cited in a symbol list.
- Protected GKI modules can't be overridden by vendor modules.
A protected GKI module is the default class of GKI modules. All GKI modules are considered protected at the time of KMI freeze.
Unprotected GKI Module
An unprotected GKI module can be overridden by a vendor module. After KMI freeze, a protected GKI module might be reclassified as unprotected if the GKI team decides that vendors need to override the default implementation with a version that includes new features from upstream Linux. On the next GKI release, unprotected modules are reclassified as protected after upstream code lands in an Android Common Kernel (ACK). Unprotected GKI modules have the following characteristics:
- Unprotected GKI modules have the same access to exported symbols as vendor modules.
- Unprotected GKI modules can't export symbols exported by protected GKI modules.
- Unprotected GKI modules must preserve any KMI interfaces as though part of the core kernel.
- Unprotected GKI modules can be overridden by vendor modules.
A vendor module is delivered by partners to implement SoC and device-specific functionality. Any existing kernel module that isn't delivered as part of the GKI kernel can be delivered as a vendor module.
Since one of the primary goals of the GKI project is to minimize
hardware-specific code in the core kernel, vendors can expect that the GKI
kernel won't include modules that are clearly managing their own hardware. For
example, vendor ABC Inc, can expect that configs such as
CONFIG_ABC_SOC_SUPPORT won't be enabled either as built-in or loadable
GKI modules without their support.
If a kernel driver or framework exists in ACK, but isn't delivered as part of
the GKI kernel, vendors can modify the driver and deliver it as a vendor
module. Such modifications are discouraged for non vendor-specific modules
because the same functionality might be delivered with the GKI kernel in a
future release. When the GKI kernel contains functionality provided by a vendor
module, the vendor module won't load. For example,
CONFIG_GREYBUS isn't set for GKI in Android 11, so
vendors may deliver greybus vendor modules. However,
CONFIG_GREYBUS might be
enabled as a GKI built-in or module in Android 12, in
which case greybus vendor modules won't be loaded. A best practice is to use
the upstream version of non vendor-specific drivers if they are delivered as
You can deliver vendor modules in the
vendor or the
image. Modules required early in the boot process must be in
There is a boot-time cost associated with loading modules from