Become a fan of Slashdot on Facebook


Forgot your password?
Android Google Operating Systems Software Linux Technology

With Android Oreo, Google Is Introducing Linux Kernel Requirements ( 120

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."
This discussion has been archived. No new comments can be posted.

With Android Oreo, Google Is Introducing Linux Kernel Requirements

Comments Filter:
    • by Chrisq ( 894406 )


      All we need now is Wayland and the Unity desktop

      • Re:systemd here we come!

        All we need now is Wayland

        Congratulation, you've successfully described Jolla's Sailfish OS....

        and the Unity desktop

        ...and Canonical's attempts at Ubuntu Touch.

      • Gnome 3 bloat with all normal functions removed (you'll add them with extensions and addons that breaks when there's a new update)

  • # echo "3.18" > /proc/version

    I know it's a little more complicated than that, but I know that some of those handset devs will be tempted to try just modifying the kernel number to pass the test.
    • # echo "3.18" > /proc/version

      bash: echo: write error: Input/output error

      (because /proc/version is r/o)

      • Yeaeh you would have to modify the version number at compile time.
      • by HiThere ( 15173 )

        What's weird though is that echo /proc/version yielded /proc/version even though kwrite /proc/version got the correct info.

  • ok (Score:5, Informative)

    by matushorvath ( 972424 ) on Monday September 04, 2017 @04:08AM (#55135627)

    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 (Score:5, Informative)

      by Miamicanes ( 730264 ) on Monday September 04, 2017 @04:40AM (#55135705)

      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 (Score:4, Informative)

        by Anonymous Coward on Monday September 04, 2017 @05:21AM (#55135783)

        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.

      • 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 insta
        • Good post, except that Linux does not have user space device drivers, with a few exceptions such as X11 and FUSE. Especially where performance is an issue, kernel drivers are far superior. Many of the APIs you need to write a fully capable device driver, such as registering an interrupt handler, are simply not exported to user space. Lucky for you.

          • Good post, except that Linux does not have user space device drivers, with a few exceptions such as X11 and FUSE.

            Technically correct, as user-space driver subsystems like CUPS (for printing) and SANE (for scanning) don't depend much on anything specific to Linux proper. They're used with GNU/Linux, but they're also used with (say) FreeBSD.

            • You're right that CUPS drivers are in some sense device drivers. Of course those are stacked on top of "actual" hardware drivers that access the USB port, parallel port, etc.

  • 3.18? (Score:4, Insightful)

    by aglider ( 2435074 ) on Monday September 04, 2017 @05:12AM (#55135759) Homepage

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

    • Re:3.18? (Score:5, Informative)

      by lordlod ( 458156 ) on Monday September 04, 2017 @07:05AM (#55135965)

      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? (Score:5, Informative)

      by Jody Bruchon ( 3404363 ) on Monday September 04, 2017 @10:06AM (#55136549)
      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 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.

  • by Anonymous Coward

    All SoCs productized in 2017 must launch with kernel 4.4 or newer.
    All other SoCs launching new Android devices running Android O must use kernel 3.18 or newer.
    Regardless of launch date, all SoCs with device launches on Android O remain subject to kernel changes required to enable Treble.
    Older Android devices released prior to Android O but that will be upgraded to Android O can continue to use their original base kernel version if desired.

  • by sad_ ( 7868 ) on Monday September 04, 2017 @06:50AM (#55135919) Homepage

    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.

  • by Anonymous Coward

    I'm actually surprised that Android was (is, 3.18 is 2.5years old!) permitted to use old kernels with all the bugs they had (unauthorised remote access was rarely a problem... but quite a few bugs allowed privilege scalation provided physical access, and a phone is not a computer room).

  • by gchat ( 747883 ) on Monday September 04, 2017 @07:54AM (#55136133)
    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.
    • You have two choices, here. Stop using Android or stop using smartphones.

    • Ars think that Project Treble will make custom builds easier, not harder []

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

    • You have this backwards. The goal here is to attempt to eliminate this tying of binary blobs to a kernel in a way that prevents updating. This should make it easier to do custom builds in the future.

    • by iamacat ( 583406 )

      You do realize that this is only a requirement for hardware manufacturers who want to bundle Google apps with their devices right? So far these apps don't even check much if you download them from the web and sideload. But even if some of them do in future, you can still install amazon app store and runs tons of other stuff.

    • by swillden ( 191260 ) <> on Monday September 04, 2017 @04:15PM (#55138009) Homepage Journal

      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.

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

        • by swillden ( 191260 ) <> on Tuesday September 05, 2017 @09:54AM (#55140553) Homepage Journal

          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.

          • Thanks for your kind response.

            All this was prompted by my phone randomly disconnecting and reconnecting when charging, which means late at night the screen turns itself on and off, waking me up. Google has apparently made no provision for a setting to turn off the screen when a charger is connected. The best you can do is download an app that will quickly turn the screen back off, but it will still flash randomly in a dark room, and this is annoying.

            I want the ability to go through the source code for the k

            • in the current ecosystem, it is basically impossible unless you have an unlocked device. Please correct me if I'm wrong.

              You are correct. My recommendation is to make bootloader unlockability a must-have feature when buying your next device. Sorry I can't offer more.

      • by gchat ( 747883 )
        First of all many thanks for the extensive explanation about project tremble. It's the most clearest one I've read about this project yet. I was reluctant to mention tremble because I don't have much info about it which explains it functional-wise. When I first heard about it I had the same impression as you but later as I gathered more info, 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. It is quite obvious that almost all OEM'
        • 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 fo

  • by Anonymous Coward

    I wonder how much is to simplify life for project Treble, and how much to fuck everyone with safetynet?

    Right now you can defeat the safetynet checks by having the kernel not report on the bootloader lock/unlock status, but if you enforce a 4.4.x kernel as well as publishing the config, safetynet will check the bootloader status and will see from the config if the kernel is reporting it or not. If unlocked or configured to not report it, safetynet will fail the basic checks.

    This will quickly kill custom ROMs

  • Android? Oh.


    cause you know more is always better...

  • In every environment I have ever worked in the "version number" is simply a compiled in constant. I have the kernel source, can't I simply compile in the version of the kernel that is being tested for?

"You stay here, Audrey -- this is between me and the vegetable!" -- Seymour, from _Little Shop Of Horrors_