After reading the Android documentation on General Kernel Image (GKI), i have gained an understanding of what it means for OEMs.

We know every OEM could modify the Linux kernel in earlier kernel versions (before 5.4) of Android. Some were just customizing the device driver. However, Android realized that this process could block the ecosystem, so the GKI project was developed.

For OEMs, I think the key priority should be to differentiate the Linux kernel under GKI. However, most OEMs prefer not to submit their modifications to the Linux upstream as it is their proprietary and gives them a competitive edge (or show them may lead to a loss since they may not be solid enough). To address this, GKI offers a vendor hook method, which requires OEMs to create a separate kernel module for their modifications and add a hook in GKI that will call the functions defined in the kernel module. The hook uses kernel trace point rather trace event. By using this method, OEMs can differentiate their kernel while still maintaining their competitive advantage.

Please keep in mind that the OEM/vendor must submit any hooks to the Android Common Kernel (ACK) upstream, which will then be reviewed. If the hook is reasonable, it will be accepted, but if it’s not, it will be rejected. It’s crucial to consider this when adding a hook to your feature since it could potentially be rejected.

Additionally, I’d like to point out that before the GKI was introduced, there were people who liked to make random modifications to the kernel. We weren’t sure whether these changes were good or bad because we weren’t familiar with the areas they were modifying. They simply had more exposure to those areas than we did. The emergence of GKI allows us to identify whether something is a mule or a horse.

Returning to the topic, are there any other ways to customize the kernel? I believe there are, and one example is eBPF. And i think we still need to submit something upstream rather than completely closed development.

Currently there are 2 GKI stages: GKI 1.0 and GKI 2.0.

In GKI 1.0, devices launching with kernel version 5.4 must pass GKI testing (Android 11 and later platform releases).

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.

Based on my undertanding, OEMs can still modify the core kernel for kernel 5.4 only if their devices pass the GKI testing and/or CTS/VTS testing. Remember, i think it’s best to avoid breaking the upgrade process which includes any core changes as well except this testing. If you’re not confident, don’t touch it. For kernel version 5.10 or above, it is mandatory that OEMs cannot modify the core kernel.

So, to summarize the methods that OEMs need to take towards the right direction:

  1. Develop a kernel module with a vendor hook.
  2. Utilize eBPF technology.
  3. Explore additional methods for customization.

Reference: