Future Android Versions

The current Android release recommends building and shipping all board-specific code as kernel modules in devices. The rest of the kernel is treated monolithically with respect to Android (whether or not it's a monolithic kernel, or parts of it are compiled as kernel modules).

This monolithic kernel is an SoC kernel that can boot on the SoC vendor's reference hardware but nothing beyond that. Today, SoC kernels are treated similar to the common kernel; they're also heavily replicated in board-specific repos. This distribution model causes them to be fixed differently for the same bug in each branch, delaying future updates to the kernel due to cherry-picking at different times or fixing the same bug differently. To counter this, SoC kernels must be a separate deliverable, with everyone who uses the SoC contributing to the same SoC kernel.

Monolithic kernel fragmentation

SoC kernels fragment over time, across Android releases, and across ODMs.

Figure 1. Device kernel replication

This example illustrates the following:

  1. It takes a significant amount of effort and time for everyone to cross-merge board-specific branches/tags.
  2. While waiting for the cross-merge, Android device manufacturers patch their own kernel for bugs/security fixes.
  3. Divergence from the ancestor make future upgrades/merges difficult.

Common SoC kernels

The proposed model for a common SoC kernel addresses problems created by upmerging changes such as SoC-specific bug fixes, LTS upgrades, and security fixes. For example, an ideal, unified-per-SoC-kernel scenario has the following workflow.

Figure 2. Android 8.x and higher device kernels

This workflow is intended to solve the problem of fragmented kernel repos by working with device manufacturers to stay up to date with the common SoC kernel. Android 8.x and higher provides all possible options to ODMs to help them avoid maintaining their own SoC kernels and instead rely on the common SoC kernel for upgrades such as LTS upgrades, bug fixes, and security patches.

As a start, we want to facilitate all ODMs/vendors using a single kernel source for an SoC. In the future, we want to move towards a single binary distribution of kernel per-SoC.

Upstreaming kernel changes

To make updating to newer kernel versions easier and more automatic, and to provide a more secure and reliable platform for ODMs on which to build a product, it's strongly recommended that SoC vendors work to upstream their kernel changes and get them accepted into the main kernel.org repository. At first, this requires extra effort and engineering, but saves time and money in the long run. Merged code is also of a much higher quality with fewer bugs and security issues (and usually smaller) than code that hasn't been reviewed by the community.

If full support for the SoC is merged upstream, the community can make needed API changes as the internal kernel API evolves over time, extending the longevity of the platform. The kernel can also be automatically tested for regressions in development and stable releases by adding the hardware platform to one of the many community-managed kernel test platforms (such as kernelci.org).

For help working with the Linux kernel community to upstream your code, refer to the following resources:

  • Documentation/process (Documentation/development-process in 4.9 and lower)
  • Documentation/CodingStyle
  • Documentation/SubmittingPatches

The community uses a minimal review process to accept standalone drivers and file systems into the staging portion of the kernel, where the community works to improve code quality.