The AOSP common kernels are downstream of Long Term Supported (LTS) kernels and include patches of interest to the Android community that have not been merged into LTS. These patches can include:

• Features tailored for Android needs (e.g. interactive cpufreq governor).
• Features rejected by upstream due to implementation concerns (e.g. MTP/PTP, paranoid networking).
• Features ready for Android devices but still under development upstream (e.g. Energy Aware Scheduling/EAS).
• Vendor/OEM features that are useful for others (e.g. sdcardfs).

List of common kernels

To view a list of Android common kernels, refer to https://android.googlesource.com/kernel/common/ (shown below).

Figure 1. List of Android common kernels

Differences from LTS

When compared to LTS (4.14.0), the Android common kernel has 355 changes, 32266 insertions, and 1546 deletions (as of February 2018).

Figure 2. Android-specific code over time

The largest features include:

• 19.8% Energy Aware Scheduling (kernel/sched)
• 13.8% Networking (net/netfilter)
• 13.5% Sdcardfs (fs/sdcardfs)
• 9.4% USB (drivers/usb)
• 7.2% SoC (arch/arm64, arch/x86)
• 6.2% f2fs (fs/f2fs -- backports from upstream)
• 6.1% Input (drivers/input/misc)
• 5.4% FIQ Debugger (drivers/staging/android/fiq_debugger)
• 3.6% Goldfish Emulator (drivers/platform/goldfish)
• 3.4% Verity (drivers/md)
• 11.6% Other

Requirements

All AOSP common kernels must provide the following:

• Method for downstream partners to get timely updates that include all LTS patches.
• Mechanism to guarantee that new feature development does not interfere with merging from AOSP common (even for previous Android releases).
• Method for downstream partners to easily identify security patches that are part of an Android Security Bulletin (ASB). This satisfies carriers who require a full requalification if OEMs attempt to include patches beyond those listed in the bulletin.

In addition, regular testing must be performed on AOSP common kernels and branches must be tagged when passing.

LTS merges

To ensure downstream partners can get timely updates that include all LTS patches, android-X.Y gets regular merges from LTS and is validated via automated VTS, CTS, and build/boot tests.

Android-dessert branches

To guarantee that new feature development does not interfere with merging from the AOSP common kernel (even for previous Android releases), android-X.Y-androidRel is cloned from android-X.Y prior to the initial dessert release, gets regular merges from LTS, and is tested against the associated Android release. For example, the android-4.4-n branch gets merges from the LTS 4.4.y branch.

Android-release branches

To ensure downstream partners can easily identify security patches that are part of an ASB, android-X.Y-androidRel-type is cloned from android-X.Y-androidRel at the time of the Android release and gets only the patches listed in the bulletin.

After the patches associated with a bulletin are confirmed to be merged into a release branch, the branch is tagged with the ASB level. For example, the tag ASB-2017-10-05 indicates the release branch contains patches from the Android Security Bulletin for October 5th, 2017. Parent branches contain those security patches, so if the android-4.4-o-release branch is tagged with ASB-2017-10-01, android-4.4-o and android-4.4 are also up-to-date with that bulletin. Example:

• Before releasing Android N MR1, android-4.4-n-mr1 is cloned from android-4.4-n.
• Only patches listed in ASBs are merged, allowing OEMs (who have strict requirements from carriers to avoid full qualification on security updates) to find the patches listed in the bulletin.
• android-4.4-n-mr2 will be android-4.4-n-mr1 plus LTS patches that were merged between the releases.
• Each month when the ASB is released publicly, the release branches are updated with any patches cited in the bulletin that are upstream (device-specific patches cited in the bulletin are not applied to the common kernels).

Regular testing

Regular testing is performed on all on AOSP common kernels and test results are available to the public. Specifically:

• After LTS updates or other patches are merged, VTS and a subset of CTS is run and results are made available at https://qa-reports.linaro.org/lkft.
• To continually test for build/boot breaks in a variety of architectures and builds, kernelci is run and results are made available at https://kernelci.org/job/android.

Branch hierarchy (android-4.4)

The branch hierarchy for the android-4.4 kernel uses the following structure:

Figure 3. Branch hierarchy for the android-4.4 kernel.

Guidelines

Android implementations should use the following kernel guidelines:

• Use the new AOSP common kernels as upstream merge sources.
  • To get patches from LTS, merge from android-X.Y.
    • Merge regularly during development phase.
    • When updating device to a new Android release, merge either from the android-X.Y branch or the release branch for the target release (e.g. for an update to Nougat MR2, merge from the android-4.4-n-mr2 branch).
  • When constrained by the carrier for a security release, merge from release branches for security updates.
• Send fixes upstream to mainline, LTS, or AOSP common.