There are two types of kernel modules: hardware agnostic GKI modules and hardware-specific vendor modules. This page provides an overview of both types of modules.
GKI modules
Generic kernel image (GKI) modules are used to deliver nonboot-required kernel capabilities separate from the generic core kernel. With GKI modules, you can choose specific kernel capabilities to use, often reducing kernel image size and runtime memory consumption. The reduction in size makes GKI well suited for Android Go devices and other resource-restricted form factors.
GKI modules also provide a mechanism to let vendors incorporate new upstream features after the KMI freeze milestone. Built-in code can’t be replaced without building another image, whereas code delivered as a module can be replaced by another module.
GKI modules use the kernel's build time signing infrastructure to differentiate between GKI and other modules at run time. Unsigned modules are allowed to load as long as they only use symbols appearing on the allowlist or provided by other unsigned modules.
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.
Vendor modules
A vendor module is delivered by partners to implement SoC and device-specific capabilities. 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 capabilities might be delivered with the GKI kernel in a
future release. When the GKI kernel contains capabilities 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
vendor modules.
You can deliver vendor modules in the vendor or the
vendor_boot
image. Modules required early in the boot process must be in vendor_boot.
There is a boot-time cost associated with loading modules from vendor_boot.