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

Comments

ok

[matushorvath]

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.

Re: ok

[Miamicanes]

Except that also means even older NEXUS devices might not be able to run newer versions once Google EOLs them. Remember, Linux kernel modules are specific to not only a particular VERSION of Linux, they're specific to a particular combination of build options on specific hardware (in contrast to Windows, which in many cases can be coaxed into using drivers that are literally 20 years old due to Windows' strong hardware abstraction).

AOSP might be open-source, but a real-world Android device built around a Qualcomm SoC is still 100% dependent upon Qualcomm making new binaries available (at least, if you want the radio modem, wi-fi, bluetooth, gps, camera, OpenGL ES, and everything else to work, too).

Re: ok

[Anonymous Coward]

Which is, strangely enough, what this is all about.

Project Treble, basically a hardware abstraction layer to stop the SoC manufacturers holding up patching etc.
(https://source.android.com/devices/architecture/treble)

Re: ok

[Dorianny]

In Windows and in LInux there are 2 types of drivers, kernel space and user space. The user space hook through a standardized interface which rarely changes and drivers will often work even across major kernel releases. Kernel space drivers can hook however they like even in methods never intended for that purpose and for this reason even minor kernel changes can break them badly. You try hooking a 20 year old chipset driver in Windows and tell me how that goes. Horrible drivers were a major source of instability in Windows until Microsoft started the WHQL (Windows Hardware Quality Labs testing ) program and literally started testing and approving drivers themselves. If you try to install a non WHQL approved driver in Windows you will get a scary prompt warning you that the driver might make the system unstable. The Linux community will not test drivers but they will be more than happy to maintain and update your drivers if you GPL them

Re:Any experts who can elaborate on this?

[93 Escort Wagon]

If the complete kernel configuration can be read, does this mean malware authors like NSA, CIA, criminals etc. will have an easier time getting inside your phone?

Not really. It seems to me all Google is doing is forcing Linux on these Android phones to behave closer to the way it already does on Linux servers and desktops.

Linux has never been about security through obscurity - that's just weirdness introduced by certain handset manufacturers.

3.18?

[aglider]

With v4.13 just released!
It's a really new OS, then!

Re:3.18?

[lordlod]

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.

Re:3.18?

[nctritech]

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.

Re:3.18?

[Tough Love]

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

The ARM subsystem was refactored a few years back in view of this. There are perfectly good reasons why SoC can benefit by doing its own thing, but the general trend is in the direction of commonality, which lowers engineering costs for everyone in the long run.

step in the right direction

[sad_]

some phones use really horrible outdated kernel versions, mostly because they have blobs in them that aren't updated.
this is a good step in the right direction, but google could still do more.

Re: Any experts who can elaborate on this?

[DontBeAMoran]

Hardware made in China, but the firmware, OS and software are made in the U.S.A. and other not-China countries.

Trying to kill Custom Firmwares?

[gchat]

This seems to me like a major hindrance for developers of custom firmwares. Since OEM's don't give a shit and don't release hardware blobs for their own devices, community developers had to use older kernels with new firmwares. For example my 4 year old Nexus 4 runs a bugfree custom Android 7.1.1 but the kernel is still the same as with 5.0, since Google stopped supporting the device and didn't release blobs for newer kernels. Now a kernel version of 3.18 for O seems fine, but there's no guarantee that newer firmwares won't have much higher requirements, like 4.0 for P etc. This would make many devices obsolete despite the high effort of those community developers, doing on their spare time the jobs that the OEM's should do.
If Google wanted to be serious about this they had to at least demand of OEM's to publish hardware blobs from now on for newer kernels. But it seems that this action is just another another step by big G to help the OEM's to accomplish more easily their planned obsolescence for any device which is over a year old.

Re:Trying to kill Custom Firmwares?

[jareth-0205]

Ars think that Project Treble will make custom builds easier, not harder https://arstechnica.com/gadget...

(I dunno I haven't used done the legwork to form an opinion)

Re:Trying to kill Custom Firmwares?

[swillden]

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.

Re:Trying to kill Custom Firmwares?

[ShakaUVM]

Wouldn't a better solution be Google requiring the bootloader code to all be free and open source, and all phones to be rootable?

The biggest problem with Android right now is how vendors lock down phones and don't give the users control over the devices they literally own.

Re:Trying to kill Custom Firmwares?

[swillden]

I realized that it could be just a way to allow OEM's to update their firmwares more easily without much effort on their part

In fact, the goal is to give OEMs the option to turn updating over to Google, making it literally zero effort (and cost!) for them. That's a pretty big step, though, so I don't think it will happen quickly, and when it does happen it will probably be second- and third-tier OEMs that do it. I hope I'm wrong on that last part.

It is quite obvious that almost all OEM's and hardware manufacturers have it on their business plan to not update older capable devices in order to force the users to change them frequently.

It may be "obvious", but it's simply not true, not that I've ever seen, and I've talked to a lot of people at a lot of OEMs.

That actual reason they're reluctant to do updates is not forced obsolescence, it's because updating is hard, which means expensive, and the vast majority of their customers do not care. Planning to do updates means including money in the business plan to pay for doing updates, and since the OEMs only do one transaction with you, that means they have to add that cost to the purchase price. The Android phone business is intensely competitive and margins for almost all of the OEMs are razor thin, so that simply won't happen unless and until customers demand it.

lockdowns from hardware manufactures needs to be stopped. Google had a big chance with the Nexus line to change this behavior and blew it.

Google did change this with the Nexus/Pixel line. All devices you buy from Google have unlockable bootloaders. This isn't something that Google can, or really even should try to, dictate to OEMs.

Look, I understand where you and ShakaUVM are coming from. I believe users should be able to fully own their devices, and so does nearly everyone else at Google. But it's not Google's job to dictate how devicemakers interact with their customers. Google's job is to make sure that Android devices are all compatible, that an app written to the standard Android APIs runs on all of them. Google has expanded that role a little with Treble, but it's still fundamentally one of compatibility, making sure that devices are compatible with future versions of Android.

Google is leading by example, and hoping that enough Android users care about unlockable bootloaders enough to vote with their wallets. So far, that hasn't worked. If you care about this, commit to refusing to buy any device without a specific commitment to vendor-provided updates, and without an unlockable bootloader, and convince everyone you know to do the same. If enough people do, OEMs will go along.

Re:Trying to kill Custom Firmwares?

[swillden]

Wouldn't a better solution be Google requiring the bootloader code to all be free and open source, and all phones to be rootable?

I won't go into detail because I'm not sure how much I can actually say, but I'll just point out that Google has to walk a very fine line. Every player in the ecosystem understands Google's role in ensuring compatibility across the ecosystem, so they're willing to accept Google's imposition of the compliance test suite (CTS). Which isn't to say they don't grumble about it and roll their eyes when they think Google is quibbling over minor details that they think don't matter, but they accept.

And I think they'll be willing to go along with the new form of compatibility demanded by Treble and the vendor test suite (VTS). CTS ensures that apps run on all Android devices. VTS aims to ensure that future versions of Android run on all Android devices (up to a point).

But there are real limits. Android is open source, and any of the big players, or a consortium of smaller ones, could fork Android and run with it. If Google steps too far out of the compatibility-enforcement role and starts trying to dictate how OEMs can do business with their customers (the carriers, mostly), the OEMs absolutely will fork Android. You think there are fragmentation problems now? And how much do you think those leading the new fork(s) will care about unlockable bootloaders?

So Google has to step lightly with mandating anything outside of compatibility. And by "step lightly" I pretty much mean "not do it". What we can do is to try to engineer things so it's easier for OEMs to do the right thing, but if they don't want to, or carriers don't want them to, we can't make them.

BTW, one note on your use of the word "rootable". That's the wrong word. Rooting is neither necessary nor sufficient to actually take control of your device. Thoroughgoing application of SELinux is actually making rooting irrelevant. Since root can't violate the SELinux restrictions, it can't really do much anymore anyway. I think we're not too far from making root just another user.

No, what you want is to be able to unlock the bootloader so you can flash custom images to it. Your custom images, of course, can eschew SELinux and make root all-powerful again, if that's what you want (though it's a bad idea, and I strongly recommend against it). But the key is that with the bootloader unlocked you can do whatever you like with the device.

Let me just insert this here

[fyngyrz]

I take offense at your use of "micro." You are impugning my manhood. My aggressions are a "good size." She told me so and that's why I know it's true.

Re:Any experts who can elaborate on this?

[Vairon]

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.