Google is committed to advancing racial equity for Black communities. See how.

Android Common Kernels

The AOSP common kernels (also known as the Android common kernels or ACKs) are downstream of kernel.org kernels and include patches of interest to the Android community that haven't been merged into mainline or Long Term Supported (LTS) kernels. These patches can include:

  • Backports and cherry-picks of upstream functionality needed for Android features
  • Features ready for Android devices but still under development upstream (for example, Energy Aware Scheduler task placement optimizations).
  • Vendor/OEM features that are useful for other ecosystem partners (for example, sdcardfs).

android-mainline is the primary development branch for Android features. Linux mainline is merged into android-mainline whenever Linus Torvalds posts a release or release candidate. Before 2019, Android common kernels were constructed by cloning the recently declared LTS kernel and adding the Android-specific patches. This process changed in 2019 to branch the new Android common kernel from android-mainline. This new model avoids the significant effort to forward port and test Android patches by accomplishing the same result incrementally. android-mainline undergoes significant continuous testing, this model ensures a high-quality kernel from the day it's published.

When a new LTS is declared upstream, the corresponding common kernel is branched from android-mainline. This allows partners to begin a project prior to the declaration of the LTS version, by merging from android-mainline. After the new common kernel branch is created, partners can seamlessly change the merge source to the new branch.

Other common kernel branches receive regular merges from their associated LTS kernel. This is normally done immediately after the LTS release is posted. For example, when Linux 4.19.64 was posted, it was merged into the 4.19 common kernels (for example, android-4.19-q). Partners are strongly encouraged to regularly merge from the common kernels into their product kernels to stay up-to-date with LTS and Android-specific bug fixes.

Terms

Here are some new terms used in this document to describe the Android common kernel policies.

Feature kernel

Kernels that are enhanced with features for the latest Android platform release are called feature kernels. For Android 11, the feature kernels are based on kernel versions 4.14.y, 4.19.y, and 5.4.y. In past platform releases, feature kernels were the same as launch kernels. However, in Android S there will be two feature kernels and three launch kernels.

Generic Kernel Image

Beginning with Android 11, Android common kernels are used to create Generic Kernel Images (GKIs), which are Aarch64 kernel images that can be used to run any device with the SoC and driver support implemented in vendor modules. For details, see the GKI overview.

Kernel Module Interface

GKI introduces the concept of a stable Kernel Module Interface (KMI) that allows the core kernel to be updated asynchronously from the vendor modules. When the KMI is frozen, then no changes can be made that break binary compatibility with existing vendor modules. See the GKI overview for details about the KMI.

Launch kernel

The designated launch kernels can be used for launching devices with a particular Android platform release. For Android 11, devices can be launched with kernels based on kernel versions 4.14.y, 4.19.y, and 5.4.y.

Common kernel branch types

KMI kernel branch

KMI kernels have a stable Kernel Module Interface. The KMI is uniquely identified by the kernel version and the Android platform release, so the branches are named <androidRelease>-<kernel version>. For example, the 5.4 KMI kernel for Android 11 is named android11-5.4. It's expected that for Android 12 there will be two additional KMI kernels, android12-5.4 and a second based on the new LTS kernel expected to be declared at the end of 2020.

Legacy dessert kernel branches

Legacy dessert kernels were created to guarantee that new feature development didn't interfere with merging from the Android common kernel. The branches were created prior to the associated dessert release and receive regular merges from LTS, but no new features. For example, android-4.9-q receives merges from the LTS 4.9.y branch.

If a kernel version wasn't a launch kernel, no dessert kernel was created, but the kernel associated with the most recent platform release is valid for upgrading to future Android platform releases. For example, android-4.4-p was the last of the android-4.4* dessert branches, so it's supported and tested with its original platform release, Android 9 (Pie). It's also supported and tested with the platform releases that support upgrades of devices running 4.4 kernels: Android 10 and Android 11.

Because the dessert naming scheme for Android platform releases was dropped with Android 10, the last dessert releases that would have been called android-4.14-r and android-4.19-r were instead called android-4.14-stable and android-4.19-stable.

Dessert kernels are superseded by KMI kernels beginning with Android 11, so the complete list of supported dessert kernels is in this table.

Android platform release Kernel Supported until
Android 8.1 (Oreo) android-4.4-o
android-4.9-o
June 2021
Android 9 (Pie) android-4.4-p
android-4.9-p
android-4.14-p
January 2022
Android 10 android-4.9-q
android-4.14-q
android-4.19-q
January 2023
Android 11 android-4.14-stable
android-4.19-stable
January 2024

Legacy release kernel branches

Release kernels are maintained to provide backports of patches cited in the monthly Android Security Bulletin. They were created for each launch kernel when there was a new Android platform release. They're deprecated when the associated kernel or platform release is deprecated as described in Support lifetimes and security patches.

Every month when the Android Security Bulletin is published, these kernels are updated with backports of the patches cited in the bulletin that are relevant to the upstream kernels and Android common kernels. They don't receive LTS patches, so the minor version number never changes. They don't contain backports for vendor-specific patches.

In Android 11 and later platform releases, partners must merge from dessert or KMI kernels to apply the patches cited in the Android Security Bulletin. No release kernel will be created for Android 11 or later platform releases.

Therefore, the complete list of 14 release kernels is shown in this table, and none will be added.

Android platform release Kernel Supported until
Android 8.0 (Oreo) android-3.18-o-release
android-4.4-o-release
android-4.9-o-release
January 2021
Android 8.1 (Oreo MR1) android-3.18-o-mr1
android-4.4-o-mr1
android-4.9-o-mr1
June 2021
Android 9 (Pie) android-4.4-p-release
android-4.9-p-release
android-4.14-p-release
January 2022
Android 10 android-4.9-q-release
android-4.14-q-release
android-4.19-q-release
January 2023

Feature and launch kernels

Each Android platform release supports launching new devices based on any of three Linux kernel versions. As shown in the table below, the launch kernels for Android 11 are android-4.14-stable, android-4.19-stable, and android11-5.4.

Because kernel upgrades aren't generally required when updating the platform release, kernels that are missing the latest features for a platform release can still be used to launch devices. Therefore kernels that were designed for Android 10, like android-4.19-q, can be used on devices even after upgrading the platform release to Android 11. Starting with Android S, there will be fewer feature kernels than launch kernels to limit the number of stable KMIs that must be supported.

Android platform release Launch kernels Feature kernels
Android 9 (2018) android-4.4-p
android-4.9-p
android-4.14-p
android-4.4-p
android-4.9-p
android-4.14-p

Android 10 (2019) android-4.9-q
android-4.14-q
android-4.19-q

android-4.9-q
android-4.14-q
android-4.19-q
Android 11 (2020) android-4.14-stable
android-4.19-stable
android11-5.4
android-4.14-stable
android-4.19-stable
android11-5.4
Android S (2021) android-4.19-stable
android12-5.4
android12-5.x1
android12-5.4
android12-5.x
Android T (2022)2 android12-5.4
android13-5.x
android13-5.y
android13-5.x
android13-5.y3

1 Where 5.x is the kernel version selected as LTS at the end of 2020.

2 Android T (2022) isn't committed and is shown only to demonstrate how the new branching model will progress in the future with two feature and three launch kernels.

3 Where 5.y is the kernel version selected as LTS at the end of 2021.

Common kernel hierarchy

Branching from android-mainline

The top level of the common kernel hierarchy is shown in Figure 1.

Creating common kernels from android-mainline kernel

Figure 1. Creating common kernels from android-mainline kernel

Notice that the new Android common kernel android11-5.4 was branched from android-mainline in 2019. In 2020, when the next LTS is declared, android12-5.x (where 5.x.y is the kernel version selected as LTS) will branch from android-mainline.

As shown in Figure 1, each kernel version is the basis for two KMI kernels. For example, the two v5.4 kernels are android11-5.4 and android12-5.4, both of which are feature kernels for their respective platform releases. This will be the case for 5.x as well; android12-5.x will be created when the LTS is declared and android13-5.x will branch from android12-5.x at the kernel feature complete milestone in Spring to allow development of features for Android T.

KMI branch lifecycle

The lifecycle of a KMI branch is shown below in Figure 2.

5.x KMI branch lifecycle

Figure 2. 5.x KMI branch lifecycle

To clarify the development process and branch lifecycle, Figure 2 focuses on the KMI branches for 5.x (where 5.x is the kernel version of the TLS release selected in late 2020).

Each KMI branch cycles through three phases indicated in Figure 2 by different colors in each branch. As shown, LTS is regularly merged regardless of the phase.

Development phase

When it's created, a KMI branch enters the development phase (dev in Figure 2), and is open for feature contributions for the next Android platform release. In Figure 2, android12-5.x is created when 5.x is declared as the new upstream LTS kernel. The second KMI branch for a kernel version might be created earlier to allow for development of the subsequent release. In Figure 2, android13-5.x is created when android12-5.x transitions out of the development phase.

Stabilization phase

When the KMI branch is declared feature complete, it enters the stabilization phase, labeled as stab in Figure 2. Partner features and bug fixes are still accepted, but KMI tracking is enabled to detect any changes that affect the interface. In this phase, KMI-breaking changes are accepted, but the KMI definition must be updated as necessary. See the GKI overview for details on KMI monitoring.

KMI frozen phase

Before a new platform release is pushed to AOSP, the KMI branch is frozen and remains frozen for the lifetime of the branch. This means that no KMI-breaking changes are accepted unless a serious security issue is identified that can't be mitigated without affecting the stable KMI. To avoid KMI breakages, some patches merged from LTS might be modified or dropped if the fix isn't required for Android devices.

When a KMI branch is frozen, bug fixes and partner features can be accepted as long as the existing KMI common kernel isn't broken. The KMI can be extended with new exported symbols as long as the interfaces comprising the current KMI aren't affected. When new interfaces are added to the KMI, they immediately become stable and can't be broken by future changes.

For example, a change that adds a field to a structure used by a KMI interface common kernel isn't allowed because it changes the interface definition:

struct foo {
  int original_field1;
  int original_field2;
  int new_field;  // Not allowed
};

int do_foo(struct foo &myarg)
{
  do_stuff(myarg);
}
EXPORT_SYMBOL_GPL(do_foo);

However, adding a new function is fine:

struct foo2 {
  struct foo orig_foo;
  int new_field;
};

int do_foo2(struct foo2 &myarg)
{
  do_stuff2(myarg);
}
EXPORT_SYMBOL_GPL(do_foo2);

For the lifetime of the KMI kernel, backward compatibility with userspace is maintained so that the kernel can safely be used for the Android platform release the device was launched with. Continuous testing with previous releases ensures that compatibility is maintained. So in Figure 2, the android13-5.4 kernel can be used for Android S devices and Android T devices. Because the Android platform release is also compatible with previous versions, the android12-5.4 kernel can be used for Android T devices either for launch or upgrade.

Compatibility between kernels

The compatibility requirements between kernels in the same LTS family are changing beginning with the new KMI kernels.

KMI kernels

The new KMI kernels maintain backward compatibility with all Android platform releases that supported the kernel version. So the android12-5.4 kernel developed for Android S can be used safely on devices running Android 11. Continuous VTS and CTS testing of the stable kernels with previous releases ensures compatibility is preserved.

The KMI is stable so that the kernel can be updated without requiring a rebuild of kernel modules in the vendor image.

Legacy kernels

The legacy dessert kernels (*-o, *-p, *-q, *-stable) aren't backward compatible across Android platform releases, but kernels from the previous two Android platform releases are supported for upgrade. Therefore, a device launched with Android 10 using a kernel based on android-4.19-q can either continue to use the android-4.19-q kernel when upgrading to Android 2020, or update the vendor-specific code to support android-4.19-stable.

Compatibility matrix

This table shows the kernel versions supported and tested with each Android platform release.

Android platform release Supported kernels for upgrade Supported kernels for launch
Android 9 (2018) android-3.10
android-3.18
android-4.4-o
android-4.9-o
android-4.4-p
android-4.9-p
android-4.14-p
Android 10 (2019) android-3.18
android-4.4-o
android-4.9-o
android-4.4-,
android-4.9-p
android-4.14-p
android-4.9-q
android-4.14-q
android-4.19-q
Android 11 (2020) android-4.4-o
android-4.4-p
android-4.9-o
android-4.9-p
android-4.9-q
android-4.14-p
android-4.14-q
android-4.19-q
android-4.14-stable
android-4.19-stable
android11-5.4
Android S (2021) android-4.9-o
android-4.9-p
android-4.9-q
android-4.14-p
android-4.14-q
android-4.19-q
android-4.14-stable
android-4.19-stable
android11-5.4
android12-5.4
android12-5.x
android-4.19-stable
android11-5.4
android12-5.4
android12-5.x1
1Where 5.x.y is the kernel version selected as LTS at the end of 2020

Support lifetimes and security patches

Android common kernels are supported until either the associated LTS kernel or Android Platform release is no longer supported. While a kernel is supported, it continues to receive LTS merges from upstream and bug fixes for Android-specific code. These fixes include all kernel security patches cited in the monthly Android Security Bulletins that are relevant to the Android common kernels.

Partners can be confident that by regularly merging from Android common kernels, they're getting all the kernel security patches possible.

Common kernel testing

The common kernels are tested with several CI systems in addition to downstream testing by vendors.

Linaro Kernel Functional Testing

Linaro Kernel Functional Testing (LKFT) tests initiate various test suites including kselftest, LTP, VTS, and CTS on a set of physical arm32 and arm64 devices. Recent test results can be found here.

KernelCI testing

KernelCI build-and-boot tests are initiated whenever a new patch is committed to a common kernel branch. Several hundred build configurations are tested and booted on various boards. Recent results for Android kernels can be found here.

Android presubmit and postsubmit testing

Presubmit tests are used to prevent failures from being introduced into the common kernels. Results aren't publicly available at this time.

Android postsubmit testing is performed when a new patch is committed to a common kernel branch. By entering aosp_kernel as a partial branch name, you see a list of kernel branches with results available. For example, results for android-mainline can be found here.

0-day testing

0-day testing performs patch-by-patch testing on all Android common kernel branches when new patches are committed. Various boot, functional, and performance tests are run. Join the public group cros-kernel-buildreports

Test matrix

Android common kernel Android Platform releases Test Suites
Master 11 10 9 (Pie) 8 (Oreo) LKFT KernelCI Pre Submit Post Submit 0-day
android-mainline
android12-5.4
android11-5.4
android-4.19-stable
android-4.14-stable
android-4.19-q
android-4.14-q
android-4.9-q
android-4.14-p
android-4.9-p
android-4.4-p
android-4.9-o
android-4.4-o
android-3.18

Contributing to Android common kernels

Generally, feature development should be done on mainline Linux and not on Android common kernels. Upstream development is strongly encouraged, and after development is accepted there, it can be easily backported to the specific ACK branch as needed. The Android Kernel Team is happy to support upstreaming efforts for the benefit of the Android ecosystem.

Submit patches to Gerrit and conform to these contribution guidelines.