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/
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.
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.
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 has worked quite well for those that tried.
I would think they would start to take things more seriously at that point.
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.
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.
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 :)
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
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:
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.