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
• Vendor/OEM features that are useful for other ecosystem partners

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 6.1.75 was posted, it was merged into the 6.1 common kernel (android14-6.1). Partners are strongly encouraged to update their 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 ANDROID_RELEASE-KERNEL_VERSION. For example, the 6.1 GKI kernel for Android 14 is named android14-6.1. For Android 15, the GKI kernel android15-6.6 was introduced.

Feature and launch kernels

Before Android 15, any of the three most recent kernels could be used for device launch. Starting with Android 15, the two most recent kernel versions can be used for device launch. The launch kernels for Android 15 are android15-6.6 and android14-6.1.

Because kernel upgrades aren't 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 14, like android14-6.1, can be used on devices even after upgrading the platform release to Android 15.

Common kernel hierarchy

Branch from android-mainline

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

Figure 1. Creating common kernels from android-mainline kernel

Notice that a new Android common kernel android14-6.1 was branched from android-mainline in 2022. In 2023, when the next LTS was declared, android15-6.6 was branched from android-mainline.

As shown in Figure 1, each kernel version can be the basis for two GKI kernels. For example, the two v5.15 kernels are android13-5.15 and android14-5.15, both of which are feature kernels for their respective platform releases. This was the case for 5.10 as well; android12-5.10 was created when the LTS was declared and android13-5.10 branched from android12-5.10 at the kernel feature complete milestone in Spring 2021 to allow development of features for Android 13. Starting with Android 15 (2024), there is only one new GKI kernel per kernel version (there is no android15-6.1 kernel).

ACK KMI branch lifecycle

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

Figure 2. 6.6 ACK KMI branch lifecycle

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

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 (labeled as dev in Figure 2), and is open for feature contributions for the next Android platform release. In Figure 2, android15-6.6 was created when 6.6 was declared as the new upstream LTS kernel.

Stabilization phase

When the ACK KMI branch is declared feature complete, it enters the stabilization phase (labeled as stable 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 and the KMI definition updated on a predefined cadence (normally every two weeks). 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 android15-6.6 kernel can be used for Android 15 devices and later devices. Because the Android platform release is also compatible with previous versions, the android14-6.1 kernel could be used for Android 15 devices either for launch or upgrade.

KMI generation number

If there is an LTS merge during the stabilization phase or a security issue or other event after this that requires a KMI-changing patch to be accepted, the KMI generation number recorded in build.config.common is incremented. The current KMI generation can be found using the uname command:

$ uname -r
6.6.30-android15-6-g86d10b30f51f

The number after the platform release is the KMI generation (6 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. After KMI freeze, 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 android14-6.1 kernel developed for Android 14 (2023) on devices running Android 15 (2024). 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 android14-6.1 kernel cannot be replaced with an android15-6.6 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 android15-6.6 kernel is not supported for devices running Android 14 (2023).

Compatibility matrix

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

Support lifetimes and security patches

ACKs 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 ACK.

ACKs might be supported for longer than the corresponding upstream stable kernel at kernel.org. In this case, Google provides extended support until the end-of-life (EOL) date shown in this section. When kernels are EOLed, they are no longer supported by Google and devices running them are considered to be vulnerable.

Beginning with kernel 6.6, the support lifetime for the stable kernels is 4 years.

This table shows the lifetimes for the supported ACKs:

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

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.