Android adopts an “upstream-first” growth mannequin for the Linux kernel


  • How Linux comes to a phone: The Linux LTS kernel is forked by Google for the Android Common Kernel, then forked by an SoC provider for each chip, then this is forked again by a device manufacturer.

  • Instead of a series of forks, Google is pushing providers to use this modular system with only one fork for the generic kernel. As usual, Google takes most of the responsibility.

The Linux Plumbers Conference is happening this week, and with Android being one of the largest distributors of the Linux kernel in the world, Google software engineer Todd Kjos stopped by for a progress report from the Android team. Android 12 – which will hit the market every day – promises to bring Android closer than ever to mainline Linux by delivering Google’s Generic Kernel Image (GKI) to end users.

Traditionally, the Linux kernel is forked several times before hitting an Android phone, usually by everyone involved in an Android device. First, Google divides the Linux kernel into “Android Common” – the Linux kernel plus a number of phone- and Android-specific changes. SoC providers such as Qualcomm, Samsung or MediaTek forks Android Common to create a SoC-specific kernel for each major chip version. Then each device receives a fork of the SoC kernel for device-specific hardware support.

Android’s kernel fragmentation is a huge mess, and you can imagine how long and difficult it is to get a bugfix at the top of the fork tree to the end where the end users live. The official documentation from states: “These modifications can be so extensive that up to 50% of the code running on a device is out-of-tree code (not from upstream Linux or from general AOSP kernels ). “It’s a big time sink too, and even Google phones usually ship kernels that start at two years old.


With the GKI, Google has set out to reduce the distance between Android and Linux. The goal is for Google to forks the Linux kernel once instead of three times for Android and to give SoC and device manufacturers space for their adjustments via plug-in modules.

Enlarge / A slide from the presentation detailing the new kernel strategy timeline.


Kjos explained, “The big pressure is to get all of the hardware-specific code out of the generic kernel and into the manufacturers’ modules. One of the big parts of this effort is that we need to have a stable interface between these manufacturers’ modules and the generic kernel modules so that they can be shipped asynchronously. “This interface is known as the” KMI “or” Kernel Module Interface “. Kjos now says that the “main difference” between the Android GKI and mainline Linux is the hooks for all of these manufacturer modules.

According to Kjos, Google prefers short hooks for these vendor modules as opposed to off-tree code because “we want to be as close to the upstream as possible”. Google is also working on bringing vendor code forward, but admits, “This is a multi-year project and we don’t expect we’ll ever make it this far.” Kjos presented a schedule for the next few years of kernel work, which sees 2020-2022 as work for upstreaming existing functions and isolating vendor changes in modules and using an “upstream-first” development model for new functions from 2023. “Since out-of-tree modules are really important to our use case, we expect that we will always have a number of exports and some things that are different or complementary to the upstream ones, but this whole project is a multi-year project for us are working to remove as many patches as possible and coordinate with the upstream as much as possible. “


The work of Google’s Generic Kernel Image is very similar to Project Treble, which created a GSI (or “Generic System Image”) that can be used to update versions of Android regardless of hardware support. Nowadays you can flash a generic version of Android to a phone and have it work for the most part, but the usual policies regarding OEM customization have resulted in generic system images not being delivered on consumer devices. The GKI is different, however, and Google actually plans to ship generic kernels to end users.

Although not mentioned in the talk, Google is working on distributing the GKI as a “Project Mainline” module that would allow kernel updates via the Play Store, where the kernel can be updated as easily as an app. We’ve interviewed members of the Android team about the GKI several times, and the plan is to not only update LTS kernel versions via the Play Store, but also to update to major new releases. Nowadays, LTS kernel updates occasionally come in via OTA updates, but devices typically don’t jump to new major kernel versions.

The timeframe for the GKI to be shipped to consumers is “Android 12,” and with this core kernel work only happening on new devices, all eyes will be on the Pixel 6 to see how ambitious Google’s first step in that direction will be . The Pixel 6 is the first device to ship with an in-house “Google Tensor” SoC, and if the theories about longer Google support schedules are correct, it would be of great help if you could skip the major kernel versions, if the support lifecycle is exceeded 5 years. Assuming the Pixel 6 ships with the Linux kernel 5.10 – which was called several times in this talk – that is a big improvement over the usual two year lag – 5.10 was released in December 2020.

Offer image from SOPA Images / Getty Images