A unified kernel won't necessarily solve Android fragmentation

Android fragmentation is a constant issue for the world’s most popular operating system. While high-end consumers are treated to a fresh Android version each year, another version comes along before it can even hit the top spot for market share. In the more affordable tiers, it’s still all too common to be a year out of date, along with infrequent updates and missing security patches.

Google has put plenty of effort into addressing the issue over the years, although it’s doubtful that Android fragmentation can ever be truly solved. Project Treble paid dividends for the adoption of Android Pie. Pie was running on many more devices in its first year than its predecessors. We’re hopefully looking at even quicker adoption of Android 10, given that a number of manufacturers were quick to offer beta programs.

Despite the effort put into speeding up OS and security updates, there are underlying issues with the way that Android works which prevent an ideal solution. At this year’s Linux Plumbers Conference (via ArsTechnica) Google pitched another band-aid for the problem, this time by trying to get Android phones to work with a generic Linux kernel rather than customized one.

Understanding the Linux kernel problem

We’ll keep this brief, as kernels are equal parts complicated and boring. The key thing to know is that the kernel is the interface between your phone’s hardware and its software processes. It’s essential if you want your phone’s software to be able to talk to its camera hardware, for example. Android is based on the Linux kernel because it’s a forked Linux-based operating system.

When it comes to Android, Linux kernel development is split into three distinct stages. Each one taking it further away from the base Long Term Support (LTS) Linux kernel that Android is based on.

First, there’s the Android Common kernel, which applies all the Android-specific features and patches to the LTS. This is then shipped off to SoC vendors (such as Qualcomm, Samsung, or Huawei), where hardware-specific patches are added. This version of the Linux kernel is then passed on to phone manufacturers, who add in their own device-specific hardware patches. This includes support for audio, camera, display, and other features.

As a result, no two phones end up making use of the same kernel. With Android, unique hardware requires a unique kernel and updating one part requires updating the entire system. Android versions have to pass through so many companies (each with their own priorities) before reaching the consumer. This is why phones are often based on two-year-old versions of LTS and why updates take so long.

Project Treble attempted to address part of this issue by separating the Android OS and hardware (HAL) frameworks. This allows functional software to be updated somewhat more independently. Google now wants to do the same right down to the low-level Linux K\kernel, opting for modular kernel components as opposed to one complete generic kernel.

Another patch on a creaking system

Google’s goal is to move to a central generic kernel and several kernel modules. The kernel modules are more hardware dependent, while the generic kernel contains the necessary patches for core Android. This would finally allow Android to operate in a way more familiar to PCs, where kernel modules are updated more like PC drivers. The core OS kernel could be updated separately, allowing for newer versions of LTS to hit the market faster.

In theory, this would make it much easier to apply software and security updates without having to worry about hardware. However, it’s likely that compatibility tests would still be required and involvement from SoC and hardware vendors would still be needed at some point. How to manage all this remains an unsolved question.

Check out the video above if you’re interested in some of the finer technical details.

Unified Android kernel won’t solve Android fragmentation

There is also an important limit to Google’s proposal. Currently, Google is only suggesting that the kernel needs to be stable for a single LTS version. The idea isn’t to update between Linux versions; rather, it’s designed to enable a general kernel to work across multiple devices instead of the thousands of forked SoC and manufacturer versions that end up on devices. Applying security updates and small patches would be much easier this way, but major OS updates might still not be so easy.

Despite Google clearly showing an interest in a unified Android kernel, there’s no guarantee that it can even be accomplished and certainly not any time soon. Ultimately, Android’s lower level hardware/software integration is a complex mess. Perhaps Google’s future Fuchsia OS will solve this problem instead.

Even if Google switched Android over to this scheme, it won’t necessarily solve the Android fragmentation issue. Security updates may be faster, but they still won’t necessarily be regular and major OS updates are a problem yet to be solved.