Hardening the Kernel in Android Oreo | Hacker News Reader

Hardening the Kernel in Android Oreo

android-developers.googleblog.com

223 pointsingve103 comments

Android should really use a modern kernel. All the forking mess involved in Android updates is a terrible problem predicated by the lack of generic drivers on mobile devices.

Copperhead[0] has been working to apply security patches to the kernel for some time and PostMarketOS[1] has an eventual goal of using the mainline upstream kernel. Really pulling for PMOS.

[0]: https://copperhead.co/android/

[1]: https://www.postmarketos.org/

Yes, this was my first thought as I was reading the article. A better title for it would be "Backporting Modern Linux Kernel Features to Our Really Old Kernels Instead of Doing the Right Thing and Keeping Up To Date".

I do -- I really do -- appreciate that version churn is difficult, and the Linux kernel also doesn't make it easy since they don't guarantee any stable internal APIs, but they're also adding a lot of work on themselves by having to maintain their own kernel trees that diverge significantly from mainline. They're also at the mercy (to some extent) of many chipset manufacturers and whatever they've chosen to base their efforts on.

A quick look at some kernel release timeframes from the versions they mention in the article:

    4.3  - 11/2015
    4.4  - 02/2016
    4.6  - 05/2016
    4.8  - 10/2016
    4.10 - 02/2017

The only kernel out of that list I'd unquestioningly accept as it being unrealistic to upgrade to for Oreo is 4.10. 4.8 might be a stretch since I'm guessing they'd already branched internally for Oreo by then, though they likely had a month or so of RCs that they could have used as a base before that. There's certainly risk to basing your work on a newly-released (or soon-to-be-released) kernel, but given the general high quality of kernel releases, I imagine that'd be pretty far down on their list of risks. Regardless, 4.6 or 4.7 would be entirely reasonable to use as a base, and since they own the conformance test criteria, they could also require that all their vendors use that as a minimum version.

And yet, they are backporting some features as far back as 3.18, which was originally released in December of 2014, and, while it was designated a LTS kernel, it, at this point in time, has moved into end-of-life status. And we wonder why Android security is a nightmare.

Main reason is that there is a lot of hardware that never got binary blobs / drivers updated for newer kernels.

We're talking input controllers, wifi, bluetooth, nfc chips, gyroscopes, amps and half a dozen other parts that never attempted to have drivers mainlined in Linux kernel.

It's a chicken and egg problem - they won't make updated blobs until Android doesn't include newer kernel. Android won't use newer kernel because that would block 2/3 of the phones from being upgraded because of Broadcom bluetooth chips alone - Samsung might decide they are better off forking Android than waiting for Broadcom.

Edit: Sony has a bunch of phones that can run on 4.4 kernel: https://developer.sonymobile.com/open-devices/

The Galaxy S8 runs 4.4, and has since release. Oreo the AOSP uses the 4.10 headers. But ultimately any vendor can integrate with a wide variance of kernels depending upon their needs.

Yes, and I addressed that in my comment. Google, however, can effectively do whatever they want. If they require kernel X, and a manufacturer doesn't support it, they'll either get their shit together, or they'll get left behind. I bet most of them do enough business supplying parts for Android phones that they'd get their shit together. And it' not hard! Writing an initial driver for some hardware might take a lot of effort, but keeping it up-to-date as new kernel releases happen will not, at least in the vast majority of cases.

I expect if google had that strength in position, they would. Perhaps that would lead to more fragmentation and less vendors releasing the latest android, leading to a highly dominant maker squashing the others and then having a stronger position in negotiating with google.

Perhaps it would be more desirable to reduce dependency on blobs? What can we do to encourage manufacturers to release source for their hardware? I assume they care about selling hardware and the firmware is just incidental?

Even when full source is available it doesn't really solve the problem. Many of the drivers provided for android socs are very poor quality and would not be allowed in the kernel. Typical problems include not using linux conventions for config parameters(device tree) and duplicating large portions of existing kernel functionality.

Not getting into the tree is a problem because kernel interfaces change all the time. When someone changes a kernel interface they are expected to update all of the affected code, but out-of-tree drivers don't get that.

> If they require kernel X, and a manufacturer doesn't support it, they'll either get their shit together, or they'll get left behind.

This leaves Google with a version of Android that does not run on anything. There are less than a handful of relevant SoM manufacturers that are capable of delivering consumer grade SoMs capable of running hardware accelerated Android; Google can not alienate these.

For sure Google can do it, what would they do, sell handsets with their own OS, based on a fork from GNU/Linux?

It has worked quite well for those that tried.

What would they do? Sell handsets with a years-old Android, of course. Experience shows that the average customer doesn't give a shit about Android versions.

Which in such scenario wouldn't be able to talk to Google Play Service servers any longer, if Google was actually serious about doing it.

It also leaves those manufacturers without anything to put on their hardware.

I would think they would start to take things more seriously at that point.

I'm insure about who has the upper hand, but I feel like SoM manufacturers know what they are doing and are where they are based on merit whereas Android is there because it was available when it mattered and gained momentum, not because of any technical merit. Android as a developer ecosystem is a train wreck. I have better tooling for deeply embedded bare metal platforms than I have for Android userspace applications.

Apple seems to have no problem keeping drivers/blobs for their hardware working when they release new versions of iOS. Sure, they do have the advantage of tight control over their hardware and core software, and a vastly smaller number of pieces of hardware to target, but in that way they're not that much different than any random Android vendor, hardware-wise. Sony (for example) is perfectly capable of only choosing vendors that can keep up with kernel versions, or at least vendors that will be open enough with them (not even with the public, just Sony) so that Sony can hire a software team to keep things up to date.

But they don't care enough about this sort of thing (unlike Apple), and no one (such as Google) is forcing them, so it won't get done unless they see an economic upside.

It's not like more than 1% of android phones that have shipped to date will actually get an android update to Oreo anyway so why not leave them behind and update the kernel?

New phones need new drivers which must support the new kernel, period. I don't see what the big deal is. You aren't getting Oreo on your old ass Samsung Galaxy S2 anyway.

Nougat runs fine on a Galaxy S2 with Lineage OS. I would not be unexpected for them to port Oreo eventually too.

GP's point was about OEM support for newer versions of Android, though; I can't imagine that third-party ROMs on old devices are even slightly a factor in Google's hesitation to upgrade to newer kernel versions

Most manufactures don't update their phones to newer version of Android anyway. I think Google should bite the bullet and upgrade to the newer kernal or atleast inform now that the next year Android will be on the latest kernal so hardware manfacturers should upstreaming their patches.

If they are backporting features well, they're approaching kernel development very similarly to the datacenter.

As an example, the standard server at $large-dayjob-server-farm runs on RHEL 6, with RHEL 7 (the latest release) being used for new machines. Both are still supported for quite a few years into the future. Let's look at their kernel versions: (per https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux)

"6.9, also termed Update 9, March 21, 2017; 5 months ago (kernel 2.6.32-696)"

"7.4, also termed Update 4, August 1, 2017; 28 days ago (kernel 3.10.0-693)"

Upstream release timelines: 2.6.32 - Dec 2009 3.10.0 - Jun 2013

Both of these upstream releases are YEARS older than both "current" and what many Android devices are using today - we'll have machines running some patched version of 2.6.32 a decade after its initial release!

So there's obviously a difference in quality of backports and updates here and some grey area in between. I can't with a straight face say that either Red Hat or Google are right or wrong in their approaches here, it's just very different than the frequent-release model that some people are used to.

The comparison isn't fair you as a user of RH, expend an effort to upgrade and the benefits are often not clear so you don't

RH as a vendor has to backport because their users demand a long supported and modern-ish kernel

Google spend time and effort to backport and this story is discussing the benefits vs putting that effort in upgrading.

Your analogy isn't fair, thou obviously android's customers here are the device makers and they are tilting the balance towards backport

That's a very good point.

My understanding, though, is that RH etc. do that mainly for stability reasons. Their customers don't want latest-and-greatest, they want small evolutions of the stuff they know works, with only bug-fixes and must-have new features.

Of course, that comes with downsides too: build your infra on RHEL 6.x, and then once 6.x becomes end-of-life, upgrading to the new latest release is a huge undertaking.

I think RHEL is doing the right thing because it's what their customers want; I would argue that in many cases their customers are doing the wrong thing and should make more-frequent, smaller upgrades rather than one giant upgrade twice a decade. But that's certainly open for debate and reflects only my experience managing infra ;)

With something like Android, I'd expect the pendulum to swing a bit the other way: you don't want bleeding-edge or unstable, but you probably do want something quite a bit more up-to-date than something that RH pushes out. To use your example, I'd say releasing a phone in 2017 based on 2.6.32 (released nearly 8 years ago!), even with 696 patch releases, would be unacceptable.

But yeah, where do you draw the line at acceptability? I personally think you shouldn't be going with a kernel release whose series was released more than a year or so before you start development (assuming getting to a release is going to take 6-12 months from that point), and ideally you just take whatever is the latest stable when you start development, if that's possible. Sure, opinions differ, but that's kinda the point... this is my opinion :)

Agreed, but let's point fingers at the whole stack if we want this to happen.

Treble [0] will finally add a HAL to the base system, so updates to the kernel and drivers should in theory be easier on devices that ship with 8.0 (of which there are exactly zero so far). So at least Google's on the right track.

But Google doesn't create the drivers and Google doesn't ship the board support packages which vendors build upon. And so we come to Qualcomm, Samsung, Mediatek, and whoever else is shipping proprietary drivers for their SoCs and radios, and who don't provide binaries for new ABIs.

The workaround is libhybris, which Ubuntu Touch, Sailfish, and now PMOS are using to support drivers built against Android kernels and its userspace, but that is so fraught with issues that it can't possibly be supported by Google or the vendors.

So we have Android 8.0 shipping with a 4.4 minimum to support the lowest common denominator of BSPs, and it kind of has to be that way until some market force changes the landscape. I don't have high hopes for either of the projects you mentioned, sadly.

[0] https://source.android.com/devices/architecture/treble

Agreed, it really is a shared problem. It seems like a kind of "collective action problem" [1], where coordination between different parties is required - but they all have different interests and they're not all interested in splitting the costs.

Google is in a difficult position. In order for Android to catch up to the iPhone they needed to encourage a wide consortium of vendors to adopt and sell Android hardware. Part of the way they encourage vendors to sell Android phones is by being very permissive about how vendors install, update and use Android. This helps Android by growing market share.

Unfortunately, it leads to a lot of variation and fragmentation in devices, which in the long term can hurt the Android ecosystem. I guess there's a balance that Google is trying to strike between being too permissive and too restrictive in how they work with vendors.

[1] https://en.wikipedia.org/wiki/Collective_action#Collective_a...

It worked for Microsoft to impose hardware designs on PCs, the big difference was that OEMs did not had the source code of MS-DOS and later Windows available to them, to do whatever they felt like it.

OEMs can't do whatever they like with Android outside of China PR. They need Google play services.

Yet Google decides, sadly for us, not to use that as enforcement for the updates.

Indeed. Google has the power, and that excuse that Android is open source and therefore Google can't impose anything on OEMs is getting a little old and tired.

If Google would have promoted Android the way it did with Chrome OS (and the open source Chromium OS), it wouldn't be in this situation, and we'd be getting updates often. But I guess hindsight is 20/20. I still wish they did more about the support of Android devices throughout the ecosystem, not just for the highest-end devices.

> we come to Qualcomm, Samsung, Mediatek, and whoever else is shipping proprietary drivers for their SoCs and radios, and who don't provide binaries for new ABIs.

Vote with your wallet.

The librem 5 mentioned this week uses a 'liberated' i.MX6 chip because they want a phone with an upstream kernel. Technology wise, it's a little long in the tooth, but they're emphasising it's possible to not reward vendors for bad behaviour.

With RPi providing resources to de-blob and upstream the Pi, perhaps some entrepreneur will get behind a crowdfunded Broadcom based phone, with work underway on VC5.

http://phoronix.com/scan.php?page=news_item&px=BCM7268-DRM-W...

Yes, they should use modern kernels but that has not happened yet. I am appalled by the practice of keeping customers on old software and sometimes even without proper security patches.

I hope regulators (EU in particular) will act on this and require manufacturers to provide support for products for a reasonable amount of time.

Devices should be clearly labelled with a "best before" date, until which the vendors should provide (at least) security updates. Right now the situation is unbearable, you buy a phone for $200 to $700 and you don't know how long it is good for. A technically oriented or security minded person can deal with the situation but almost everyone has a smartphone. Billions of unsecure devices out there isn't good for anyone.

It shouldn't be unreasonable to assume that a smartphone should be good for 5+ years.

The big issue with this is the – afterwards you always know better – completely stupid decision of Torvalds to never support a stable API for kernel modules, or drivers.

A similar issue happened recently between AMD and the kernel maintainers (AMD wanted a stable API for GPU drivers that would allow the same drivers to run on Windows, Mac, desktop Linux, and Android; and AMD had already built this API and was willing to maintain it).

In the end, this can only be solved if the Linux kernel gets a stable driver API, and with Oreo, Google added exactly that for their own fork of the kernel.

> The big issue with this is the – afterwards you always know better – completely stupid decision of Torvalds to never support a stable API for kernel modules, or drivers.

It's not stupid. APIs need to change eventually. Even famously backwards-compatible Windows has its fair share of API changes. And when public APIs change, you can either drop support for the old one (thereby also dropping support for old hardware), or provide a compatibility mapping from the old to the new API (if that is even possible).

Linus knows that he does not have the manpower to do either. All he can realistically do is only support the current API, and require devs who change the API to update all usages inside the kernel source tree when doing so.

There’s several problems with this.

(a) all drivers live in kernel space, even the sketchy drivers you have to download from NVIDIA

(b) if a driver wants to be included easily, it needs to become part of the kernel source tree, but that can only happen if Torvalds and his maintainers get full control.

As a result of all of this, the kernel maintainers refused even in any way to cooperate with AMD on their open driver (AMD needs a stable layer at some point to run the same additional functionality on windows, mac, and linux – the alternative is no linux support), we get ancient drivers on Android, with Google building their own HAL, and more shit.

At the same time, the syscalls, where maintaining a stable API is completely irrelevant and could simply be done via a small userspace library that you call to instead of doing actual syscalls, and which also massively would improve security if the translation between old and new syscalls would happen in userspace, is the one thing Torvalds maintains in the kernel.

The decisions made by Torvalds are reckless, massively hurt security and usability of open source, and the entire concept of open source ("we’d rather have only a proprietary AMD driver than an open AMD driver that relies on an HAL").

Place the blame squarely at the feet of vendors like Qualcomm - they won't update the BSPs.

Glad we are making it more secure. On a side note I love that we now have https://googleblog.blogspot.com/index.html http://blog.google and https://android-developers.googleblog.com/ and https://googleblog.blogspot.com/ (which redirects to blog.google without index.html because it appears to be the new site) which is slightly weird.

Only one of those works for me (the top one), which amusingly redirects to blog.google which you missed :)

Try it now it appears index.html isn't optional which frankly is even more confusing.

Top one works now (by which I mean doesn't redirect to what I think is the actual Google blog now...) :)

Did you mean https://www.blog.google/?

Yes apologies. Fixed in edit.

Hmm, I recall this being a much cleaner https://blog.google before. I wonder why they added www. after some time? Anyone happen to know the story?

Great to see Google linking to the LWN articles on these features. I always like to see LWN get noticed for their fantastic kernel work.

It's the primary reason I've been a subscriber since they introduced subscriptions all those years ago.

"Android 8.0 makes KASLR available in Android kernels 4.4 and newer."

And yet on my pixel with Android 8.0, I am only using 3.18.52. Who actually ships Android with kernel 4.x?

I also have 3.18 on my Pixel XL. I assume the unreleased Pixel 2 devices will be running kernel 4.4 if that's what they targeted.

They probably wanted to back port it to 3.18 but it was too much work. I'm pretty disappointed they didn't move the Pixel forward to a new kernel though, this seems to be one of the biggest issues with Android.

Quite disappointing, yet another bad example for OEMs.

I hope so, but given that 3.18 was released almost three years ago I am not holding my breath.

This is an interesting case study in development cycles. The Pixel XL from October 2016 uses the Snapdragon 82x released in July 2016 but first announced in March 2015 and it uses a kernel from 2014 which gives us a hint about when driver development started.

I was surprised to read that in the article.

New android phones from top vendors (not the $50 junk devices) ship with 3.x kernels?

Wow.

3.x kernels with security patches. What seems to be the issue?

You can claim big rewards from Google if you report kernel exploits in Android.

> 3.x kernels with security patches. What seems to be the issue?

Limiting the scope of vulnerabilities before they are patched.

There's plenty of more recent defence-in-depth work that will make some vulnerabilities impossible to exploit on more recent kernels, and while they will get patched on the older kernels it'd still be nicer if they weren't exploitable in the first place.

Even without that there are lots of power saving fixes that get put into Linux with every release. That kind of stuff seems like it be very important in a phone as well.

Given Android has its own power management story independent of what upstream is doing those power changes are unlikely to be relevant or significant to Android.

I know (vaguely) that android has its own power management system, and I don't know how much it ties into what the kernel uses on a standard laptop.

But the changes to the normal kernel one as well as some of the changes in data structures are algorithms designed to be more efficient in the first place are probably still useful.

The new pixel 2 phones coming out in October are on 4.4

My Nexus 5X, only a year older than your Pixel, is on 3.10, so it got none of these updates :(

OnePlus ships modern kernels.

My OnePlus 5 is using kernel 4.4.21 - this is with Nougat 7.1.1, by the way; no Oreo here yet.

Ok I am very disappointing with Google in that case

The kernel you get is entirely up to the SoC vendor.

Snapdragon 820/821 ships with 3.18. Snapdragon 830 ships with 4.4. Snapdragon 830+1 will ship with 4.9

There's a huge amount of work involved in porting a chipset from one kernel version to another. While I'm sure Google _could_ do it, it's ultimately not worth their while - they'd probably lose support from Qualcomm, and if they hit any weird bugs they'd be on their own.

OnePlus ships the kernel that Qualcomm gives them. The BSP for Snapdragon 835 (aka msm8998) is based on 4.4

My Galaxy S8 is running kernel 4.4.16

4.4 is old. Technology - especially software moves fast and it’s been 9 months since 4.4 was released. There’s been a lot of security, performance and feature improvements since 4.4 was released.

Major and/or userland problems don’t tend to occur as the kernel gets developed and released. There are major advantages in accepting new subsystem code over patched ‘legacy’ code.

I got the OnePlus 5 and it has kernel 4.4.21 tho using android 7.1

Nice set of features, that the majority of Android users will only get in a few years.

Maybe we should start making bets if Android Oreo be able to beat Nougat and be above 13.5% next year this time around.

You probably know this but because of project Treble for future versions after Android Oreo will probably be adopted more quickly. It is unlikely for Oreo to do much better then Nougat then from what I have read.

Anyone beliveing that project Treble will change anything should listen to the ADB Podcast about it.

http://androidbackstage.blogspot.de/2017/08/episode-75-proje...

Key points:

1 - Google will keep on allowing OEMs to customize Android

2 - OEMs will keep being responsible for delivering updates

3 - OEMs are advised to push fixes upstream and provide updates

Given that they are just advised, and not required to act accordingly, do you want to bet how many will provide Treble updates instead of selling new handsets?

That's not what this top comment says https://news.ycombinator.com/item?id=15066729 at least that's how I interpreted it.

Listen to the podcast.

You are dead on. The problem is incentives. There is no technical solution to solve the issue of OEMs not wanting to spend time/resources on updating older phones.

Treble will help out LineageOS, CopperheadOS, and XDA devs. But it won't improve the update cycles for OEMs when their business (ie profit aims) pressures them to limit development resources to new phones.

but wouldn't treble allow for there custom Android to be updated across there fleet of devices where currently each product has to get its custom build with drivers etc.

Yes this is how I interpreted it but I'm sure the other people here probably know much more which leads me to believe that must not be the case.

Which iteration of "project that will definitely reduce Android device fragmentation and ensure that all capable devices will get the new software version as soon as possible" are we on at this point?

Is it the one where vendors are upstreaming their drivers to Linux mainline, properly supporting them in tree, and users are able to audit and trust their phones for the first time ever?

Because that is the actual answer. Everything else is a compromise trying to please vendors who are only trying to exploit users for profit through planned obsolescence and withholding knowledge of how their devices work.

I like to see Android add System GUI to monitor:

* all apps (including daemon processes) that makes internet connections.

* Where they are connecting to.

* AND give user to GUI/Options block those connections.

I also want Android give users option to audit/monitor all new programs, .so, files that has been added to the systems and by which program, time.

If there are suspicious file that is added to the system, we can audit/monitor/report/google where it comes from.

In Windows 10, I use netstat to monitor all TCP connections and get the name of the programs and configure the windows firewall to only allow Windows Firewall/Firefox and Chrome to access internet and block IE/Edge/svchost/SearchUI and countless other SW from access internet. My system is so much faster and stable, after I did this.

This can be done with apps already although you have to start them on reboot in my experience. Let me go fine the name. It is called NoRoot Firewall.

This is great, never knew of this before now. Thank you.

Another one (at least for the 'monitor' portion) is Net Monitor (https://f-droid.org/packages/org.secuso.privacyfriendlynetmo...) which is available in F-Droid (https://f-droid.org/).

I'm not sure I see what security value these features would add for ordinary users.

On a modern device, most application processes will be making some sort of network connections, and many of those connections will be to IPs that can't easily be identified, even by an experienced user. (For instance, a lot of those addresses are likely to belong to Cloudflare or other CDN providers.) You can't rationally expect users to make intelligent decisions about whether to allow or block those connections.

IMO, it shouldn't be possible at all for applications to run code that's created/downloaded at runtime. iOS has the right approach here. This makes monitoring those files unnecessary -- the only path for code to enter the system is through installing or updating apps.

use "NoRoot firewall" to give access to some application :)

Xprivacy?/

For similar content but in much greater depth, this is a pretty excellent series of blog posts:

https://outflux.net/blog/archives/2017/07/10/security-things...

can you recommend any other blogs like this?

I really wish Ubuntu touch was more complete. I would switch in a heart beat.

Don't hold your breath. The project was effectively cancelled in April. There's theoretically a "UBPorts" project that may continue development, but, without any sort of company backing it anymore, I doubt that it's going to have much of an impact.

https://insights.ubuntu.com/2017/04/05/growing-ubuntu-for-cl...

'theoretically?' It's happening, albeit without a corporation behind it.

They have a weekly youtube vodcast, if you're curious, and a Patreon page with a couple of hundred subscribers.

Glad to see improvements are coming! Articles like this make me more and more curious whether Fuchsia is an alternative bid to resolve relevant kernel vulnerabilities in a more centralized, architecturally driven fashion, not just a way to get out from under the GPL.

Switching to Fuchsia (which will never happen because it is a toy project to occupy bored engineers) does not magically solve the problem that device vendors want to minimize the work in maintaining their drivers. Even enforcing open source drivers (for the sake of discussion) will not help, because at a certain complexity, the device driver writer requires knowledge about undocumented internals of the device that is just not available outside the manufacturer.

There must be an economic incentive for device manufacturers to maintain/update their drivers, otherwise it cannot happen. Users want to buy new devices, not pay directly or indirectly for updating their old devices; this basically seals the deal.

Toy project? I doubt that. There is frantic work going on by perhaps more than a hundred engineers if I am not mistaken: https://fuchsia-review.googlesource.com/

No credits given to the PaX Team / Grsecurity :(

(PAX_USERCOPY)

Are you surprised given the highly public pissing war that has been going on between Google's kernel engineers, Brad Spengler, and the PaX people?

Yes. I'd expect them to take the high road and give credit.

Did they have to license the name?

Assuming you are referring to the name Oreo read this. https://android.stackexchange.com/q/181818

EDTI: Fixed so they didn't pay as stated above but I guess it is technically still licensed.

the link says they didn't pay, not that they didn't license the name

My understanding was you can use a trademarked name but only if it was in an unrelated category. Clearly no one will confuse a phone running Oreo with a cookie you eat and dip in milk. now if google made a cookie and called it oreo, they would get sued. But IANAL and am probably totally wrong here.

Google extremely obviously did not use the name Oreo without asking for permission

From the last time this was asked, they asked permission. With KitKat, they paid - someone linked a citation for it but it's not in my history.

What I read at the time is that no money was paid to anyone. Hope you find the linked citation

https://techcrunch.com/2013/09/03/google-strikes-bizarre-lic...

I stand corrected. Well, at least I am not seeing their source.

Indeed, and the biscuit company may well have paid Google for the advertising.

Your understanding covers the basic intent of U.S. trademarks, but it got much more complicated with the Federal Trademark Dilution Act of 1995: https://en.wikipedia.org/wiki/Federal_Trademark_Dilution_Act. Nowadays, impairing a famous trademark's distinctiveness can be an issue, even in the absence of confusion or competition.

https://www.android.com/versions/oreo-8-0/

See the huge Oreo cookie there? I honestly don't understand why you made this comment.

If it's anything like the KitKat situation, no money exchanged hands, but both companies used it as a cross branding deal.

Hardening an old turd.

Reply on news.ycombinator.com