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 (AOSP experimental), the GKI kernel android15-6.6
was
introduced.
Feature and launch kernels
Before Android 15 (AOSP experimental), any of the three most recent kernels
could be used for device launch. Starting with
Android 15 (AOSP experimental), the two most recent kernel versions can
be used for device launch. The launch kernels for
Android 15 (AOSP experimental) 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 (AOSP experimental).
Android platform release | Launch kernels | Feature kernels |
---|---|---|
Android 15 (AOSP experimental) (2024) |
android15-6.6
android14-6.1
|
android15-6.6
|
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
|
android11-5.4
android-4.19-stable
|
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 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 (AOSP experimental) (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 (AOSP experimental) 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 (AOSP experimental) 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 (AOSP experimental) (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 devics running
Android 14 (2023).
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 15 (AOSP experimental) (2024) |
android15-6.6
|
android15-6.6
|
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
|
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:
ACK branch | Launch date |
Support lifetime (years) |
EOL |
---|---|---|---|
android-4.19-stable | 2018-10-22 | 6 | 2025-01-01 |
android11-5.4 | 2019-11-24 | 6 | 2026-01-01 |
android12-5.4 | 2019-11-24 | 6 | 2026-01-01 |
android12-5.10 | 2020-12-13 | 6 | 2027-07-01 |
android13-5.10 | 2020-12-13 | 6 | 2027-07-01 |
android13-5.15 | 2021-10-31 | 6 | 2028-07-01 |
android14-5.15 | 2021-10-31 | 6 | 2028-07-01 |
android14-6.1 | 2022-12-11 | 6 | 2029-07-01 |
android15-6.6 | 2023-10-29 | 4 | 2028-07-01 |
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 | 15 | 14 | 13 | 12 | 11 | 10 | LKFT | KernelCI | Pre Submit | Post Submit | 0-day | |
android-mainline
|
✅ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✅ | ✅ | ✅ | ✅ | ✅ |
android15-6.6
|
✅ | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ | ✅ | ✅ | ✅ | ✅ | ✅ |
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.