Android common kernels

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. These merges are 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.

ACK KMI kernel branch

GKI 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 GKI kernel for Android 11 is named android11-5.4. For Android 12 there are two additional GKI kernels, android12-5.4 and android12-5.10.

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.9-q was the last of the android-4.9* dessert branches, so it's supported and tested with its original platform release, Android 10. It's also supported and tested with the platform releases that support upgrades of devices running 4.9 kernels: Android 11 and Android 12.

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 GKI kernels beginning with Android 11, so the complete list of supported dessert kernels is in this table.

Android platform release Kernel Supported until
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
December 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 GKI 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 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 12, 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 14 (2023) android14-6.1
android14-5.15
android13-5.15
android13-5.10
android12-5.101
android14-6.1
android14-5.15
Android 13 (2022) android13-5.15
android13-5.10
android12-5.101
android12-5.41
android11-5.41
android13-5.15
android13-5.10
Android 12 (2021) android12-5.10
android12-5.4
android11-5.41
android-4.19-stable
android12-5.10
android12-5.4
Android 11 (2020) android11-5.4
android-4.19-stable
android-4.14-stable
android11-5.4
android-4.19-stable
android-4.14-stable
Android 10 (2019) android-4.19-q
android-4.14-q
android-4.9-q

android-4.19-q
android-4.14-q
android-4.9-q

1 Additional restrictions may apply if the associated BSP has been updated for the platform release. In more general terms, the Android Release number of the kernel must be higher than or equal to the target FCM version. See Vendor Interface Object - match kernel branches for details.

Common kernel hierarchy

Branch 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 android12-5.10 was branched from android-mainline in 2020. In 2021, when the next LTS was declared, android13-5.15 was branched from android-mainline.

As shown in Figure 1, each kernel version is the basis for two GKI 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.10 as well; android12-5.10 was created when the LTS was declared and android13-5.10 will branch from android12-5.10 at the kernel feature complete milestone in Spring 2021 to allow development of features for Android 13.

ACK KMI branch lifecycle

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

5.10 ACK KMI branch lifecycle

Figure 2. 5.10 ACK KMI branch lifecycle

To clarify the development process and branch lifecycle, Figure 2 focuses on the ACK KMI branches for 5.10.

Each ACK 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 ACK 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.10 was created when 5.10 was declared as the new upstream LTS kernel. The second ACK KMI branch for a kernel version might be created earlier to allow for development of the subsequent release. In Figure 2, android13-5.10 is created when android12-5.10 transitions out of the development phase.

Stabilization phase

When the ACK 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 ACK 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 ACK 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 GKI 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 android12-5.10 kernel can be used for Android 12 devices and Android 13 devices. Because the Android platform release is also compatible with previous versions, the android12-5.4 kernel can be used for Android 13 devices either for launch or upgrade.

When entering the frozen phase, the branch is git-tagged with the KMI version string containing the KMI generation number. For example, when android11-5.4 was frozen, it was tagged with the KMI version string 5.4-android11-0 where the trailing 0 is the KMI generation number. If there is a security issue or other event that requires a KMI-changing patch to be accepted, the KMI generation number is incremented and the branch retagged. For example, if such a change is accepted into android11-5.4, the branch will be tagged with the new KMI version, 5.4-android11-1. The current KMI generation can be found using the uname command:

$ uname -r
5.4.61-android11-0-00153-ga972f59040e4

The number after the platform release is the KMI generation (0 in this case).

If the KMI generation changes, the kernel isn't compatible with vendor modules that conform to the previous KMI generation, so the modules must be rebuilt and updated synchronously with the kernel. KMI generation changes are expected to be very rare.

Compatibility between kernels

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

GKI kernels

GKI kernels maintain backward compatibility with all Android platform releases that supported the kernel version. Additionally, the Android platform releases are backward-compatible with GKI kernels from previous releases. So you can safely use the android12-5.4 kernel developed for Android 12 on devices running Android 13. Compatibility is verified through continuous VTS and CTS testing of the GKI kernels with all supported releases.

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

KMI compatibility isn't maintained between different GKI kernels. So, for example, an android12-5.10 cannot be replaced with an android13-5.10 kernel without rebuilding all modules.

GKI kernels are supported for their initial and subsequent releases only. They aren't supported for older releases. So an android13-5.10 kernel is not supported on Android 12 devices.

Legacy kernels

The legacy dessert kernels (*-q and *-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 14 (2023) android14-6.1
android14-5.15
android13-5.15
android13-5.10
android12-5.10
android12-5.4
android11-5.4
android-4.19-stable
android-4.14-stable
android14-6.1
android14-5.15
android13-5.15
android13-5.10
android12-5.10
Android 13 (2022) android13-5.15
android13-5.10
android12-5.10
android12-5.4
android11-5.4
android-4.19-stable
android-4.14-stable
android-4.19-q (EOL)
android-4.14-q (EOL)
android-4.9-q (EOL)
android13-5.15
android13-5.10
android12-5.10
android12-5.4
android11-5.4
Android 12 (2021) android12-5.10
android12-5.4
android11-5.4
android-4.19-stable
android-4.14-stable
android-4.19-q (EOL)
android-4.14-q (EOL)
android-4.14-p (EOL)
android-4.9-q (EOL)
android-4.9-p (EOL)
android-4.9-o (EOL)
android-4.19-stable
android11-5.4
android12-5.4
android12-5.10
Android 11 (2020) android11-5.4
android-4.19-stable
android-4.14-stable
android-4.19-q (EOL)
android-4.14-q (EOL)
android-4.14-p (EOL)
android-4.9-q (EOL)
android-4.9-p (EOL)
android-4.9-o (EOL)
android-4.4-p (EOL)
android-4.4-o (EOL)
android11-5.4
android-4.19-stable
android-4.14-stable
Android 10 (2019) android-4.14-stable
android-4.14-p (EOL)
android-4.9-p (EOL)
android-4.9-o (EOL)
android-4.4-p (EOL)
android-4.4-o (EOL)
android-3.18 (EOL)
android-4.14-stable
android-4.19-q (EOL)
android-4.14-q (EOL)
android-4.9-q (EOL)

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.

Linux Kernel Functional Test

Linux Kernel Functional Test (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 Android common kernels. The test result summary can be found in 'Checks' tab of the code change in Android common kernel gerrit.

Android postsubmit testing is performed on new published builds in Android common kernel branches when new patches are committed to an Android common kernel branch in ci.android.com. By entering aosp_kernel as a partial branch name in ci.android.com, you see a list of kernel branches with results available. For example, results for android-mainline can be found here. When clicking the a particular build, you will find test status in the Test Results tab.

The tests defined by test-mapping with test group kernel-presubmit in Android platform source tree will be run as presubmit for Android kernel branches. For example following configuration in test/vts/tests/kernel_proc_file_api_test/TEST_MAPPING will enable vts_kernel_proc_file_api_test as presbumit test at Android common kernel code check-in.

{
  "kernel-presubmit": [
    {
      "name": "vts_kernel_proc_file_api_test"
    }
  ]
}

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
Main 14 13 12 11 10 LKFT KernelCI Pre Submit Post Submit 0-day
android-mainline
android14-6.1
android14-5.15
android13-5.15
android13-5.10
android12-5.10
android12-5.4
android11-5.4
android-4.19-stable
android-4.19-stable
android-4.14-stable

Contribute 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.