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