Slashdot Mirror
With Android Oreo, Google Is Introducing Linux Kernel Requirements (betanews.com)
Mark Wilson shares a report from BetaNews: As is easy to tell by comparing versions of Android from different handset manufacturers, developers are -- broadly speaking -- free to do whatever they want with Android, but with Oreo, one aspect of this is changing. Google is introducing a new requirement that OEMs must meet certain requirements when choosing the Linux kernel they use. Until now, as pointed out by XDA Developers, OEMs have been free to use whatever Linux kernel they wanted to create their own version of Android. Of course, their builds still had to pass Google's other tests, but the kernel number itself was not an issue. Moving forward, Android devices running Oreo must use at least kernel 3.18, but there are more specific requirements to meet as well. Google explains on the Android Source page: "Android O mandates a minimum kernel version and kernel configuration and checks them both in VTS as well as during an OTA. Android device kernels must enable the kernel .config support along with the option to read the kernel configuration at runtime through procfs."
So, they want you to run a kernel that is younger than two years old, and they want to be able to see which features it has enabled. Both perfectly reasonable requirements, most likely based or real engineering issues.
From the referenced page "All SoCs productized in 2017 must launch with kernel 4.4 or newer."
So it is only somewhat old, with a transition period to reduce the pain on their downstream.
More important is the signal that it sends to the manufacturers that they need to be using a recent kernel, not the dusty 2.6 they have on the shelf. A manufacturer designing a product now for launch in 2018/19 will be penciling in something much more recent, like the future 4.15 release, to ensure that they don't get caught out as Google steps the requirements.
This kernel version hold-back bullshit is entirely the fault of proprietary-only driver providers like Qualcomm. They write a driver module and provide it as binary-only which ties it to a VERY specific Linux kernel configuration. They need to provide us with source code. The biggest problem with Android in particular and SoC platforms like ARM or MIPS is that all the hardware stuff is closed off and there are no standards. ARM and MIPS do not have the things that make x86 platforms so easy to write an OS for (ACPI, PCI, etc.) and as a result every "platform" requires specific knowledge about the platform like what GPIO pin on what controller to tie to what function. All that stuff should be burned into a ROM somewhere so the kernel can configure itself for the hardware without needing complex tweaks and hard-coded configurations at the kernel level to make it all work.
Linux kernel drivers that are not open source are pure cancer. Lack of standard configuration specification and control methods are a secondary cancer. Given the state of things on non-x86 platforms, I'm surprised OpenWRT works at all. Bless those poor glorious developers at OpenWRT.
The Android OS is already running on your Android phone so what other code are you talking about?
This new Android Oreo requirement that the article is talking about only says that your kernel configuration must be made available via /proc/config.gz (CONFIG_IKCONFIG_PROC=y) which is readable by any user. It does not require any special script or code to read. It's a pseudo file that's a gzip compressed ASCII representation of the kernel's compile time configuration.
This seems to me like a major hindrance for developers of custom firmwares.
(Google Android engineer here, though please note that I don't work on either the kernel, or Treble, so take my comments with a grain of salt. I do own a couple of important Android hardware abstraction layer interfaces, and the client code that uses them, so I'm a knowledgeable user of Treble.)
This kernel version requirement should have no impact on developers of custom firmware, positive or negative. Project Treble, however, should make the lives of custom firmware developers much better.
Treble forces a hard boundary between /system and /vendor + kernel[1], with a consistent, tested interface between the former and the latter two components. This means that even after an OEM stops updating the kernel and hardware blobs, you will still be able to flash new system images, either official ones or custom, because those system images will have a fixed, reliable interface to the hardware using the kernel and firmware already on the device.
This doesn't mean that we want OEMs to ignore updates to kernel and hardware blobs. Security patches to those components are crucial -- especially the kernel, since that's where all of the most severe Android vulnerabilities are found. But the idea is to break the functional interdependency between specific kernel and firmware versions and the system that sits atop them, so the system can be updated at will even if the bottom layer is never updated.
This means that if you buy a phone that launches with Oreo, and can unlock the bootloader, you should be able to flash pure AOSP Oreo onto it instead of the OEM's system. Further, you should be able to customize AOSP in whatever way you like... and you should still be able to continue doing this when P, or Q, or S, etc., lands in AOSP.
Clearly there will have to be some point at which AOSP simply drops support for old hardware abstraction layer versions, and at that point the /vendor on your device will be providing APIs that AOSP refuses to use, so it'll stop working without heavier customization.
So what is the kernel version requirement about if it's all hidden behind a strong hardware abstraction boundary anyway? Security. As I said above, the most serious vulnerabilities we see in Android today are pretty much all in the kernel. If OEMs use ancient kernel versions, that means that all kernel security bugs have to be backported to those old versions. Such backporting is tedious and error-prone, and many OEMs -- especially smaller ones -- simply don't have the expertise to do it, so they don't. Google does a lot of kernel security patch backporting, but there are limits to how far back Google's engineers can reasonably support. By forcing OEMs to get onto more-current kernel versions, Google is better able to ensure that patches are at least made available to OEMs.
Note that this still will not force OEMs or carriers to actually deliver the patches. There are other initiatives under way that focus on trying to do that, but the first step is for Google to make it easy for them to apply the patches. That's what the kernel version requirements are about, setting up a situation where Google can provide the patches so OEMs can deliver them.
[1] I assume that "Treble" is a reference to the treble/bass line distinction in music, including the punning of "bass" with "base". So the /vendor partition, with all of the firmware blobs and implementations of the hardware abstraction layer APIs, plus the kernel, is the "base/bass", on which the code from the /system partition (treble) depends. Project Treble is about defining a bass line with consistent characteristics, to allow the melodic treble line to be swapped out at will, to replace an OEM melody with an AOSP melody or even a custom melody. Yeah, the musical analogy is a bit of a stretch, but it's still useful. And it's not even that much of a stretch, since some genres of music do have common bass lines which underlie a wide variety of melodies and even melodic structures.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.