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-qandroid-4.14-qandroid-4.19-q
|
January 2023 |
| Android 11 | android-4.14-stableandroid-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 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-releaseandroid-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.
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.
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-6.1
|
| Android 13 (2022) |
android13-5.15
|
android13-5.15
|
| Android 12 (2021) |
android12-5.10
|
android-4.19-stable
|
| Android 11 (2020) |
android11-5.4
|
android11-5.4
|
| Android 10 (2019) |
android-4.14-stable
|
android-4.14-stable
|
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
|
✅ | ✅ | ❌ | ❌ | ❌ | ❌ | ✅ | ✅ | ✅ | ✅ | ✅ | android13-5.15
|
✅ | ✅ | ✅ | ❌ | ❌ | ❌ | ✅ | ✅ | ✅ | ✅ | ✅ |
android12-5.10
|
✅ | ✅ | ✅ | ✅ | ❌ | ❌ | ✅ | ✅ | ✅ | ✅ | ✅ |
android11-5.4
|
✅ | ✅ | ✅ | ✅ | ✅ | ❌ | ✅ | ✅ | ✅ | ✅ | ✅ |
android-4.19-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.