They aren't Google devices. They're phones made by companies who downloaded and installed Android on them.
This issue was predicted (and observed) years ago, almost since the release of Android in fact, and is only getting worse.
That is all due to Google's own choices.
The Kernel has no stable ABI for drivers.
Manufacturers only ever develop a driver for their chips once, and then send that to the OEM. They never update.
The Linux Kernel LTS gets 2 years of updates, Google's fork about 4.
From the day a Kernel is released, to the day it ships in a phone, usually 2 years are spent integrating the blobs and code drops from the chip manufacturers.
On every kernel upgrade that breaks the ABI, those 2 years would have to be redone from scratch.
Linux can't mainline support for every exotic piece of hardware that ever shows up in a device.
Manufacturers can't keep maintaining several developers to update every single chip they release.
Google can't keep Android on 6 year old kernels forever.
Now combine these facts, and you'll see the issue.
Whenever a security issue or design change happened, their driver would also get updated and fixed with the rest of the kernel.
What the hardware manufacturers SHOULD do is create hardware with a well defined control interface that they CAN make public. Any 'secret sauce', uploaded firmware blobs, etc, should be free to re-distribute since they were too cheep to ship a ROM or EEPROM with the firmware for their device with the device.
For example, SAMSUNG might build your device, and get all of their own code openly.
But now for the US model, due to CDMA, they need to use a Qualcomm processor.
That needs a blob, and Qualcomm won't release that under an open license, nor update it.
So the OEM can either just not have CDMA support, or accept foreign blobs.
It works like this all way down the stack, down to even camera chips.
And then these devices all have custom hardware. Often hundreds of customly designed parts, with custom drivers, only ever for a single device.
Think of the Moto Z Play, withthe replacable components. Samsung phones with facial scanners. LG phones with 3D display.
One-off features that'd never get mainlined.
STILL, that stuff should be equivalent to a firmware blob that should have been baked in to a ROM or EEPROM. The actual driver controlling it should be able to be open, and for regulatory compliance should use 'magic numbers' as specified for the configuration; which as a fact of how to use that device must be configured already /not/ be covered by copyright (in the US at least).
But they don’t.
So while you’re absolutely correct from a technical perspective it’s still a consequence of Googles strategy, and a problem for us all.
Yes of course it's not free and you can save money by leaving users stranded. But it's myopic to claim it's the fault of Linux.
Let’s imagine you try to build a phone.
You buy an SoC, and you get a single kernel build. If you’re lucky, you get a few binary kernel modules.
These will never be updated.
You will always be stuck on that kernel version.
No manufacturer of ARM SoCs for phones currently provides ever updates for these.
Linux LTS Kernels get 2 years of support.
Now, tell me, how do you support a kernel that was dropped by upstream, with proprietary drivers that you can’t do anything about? I’m not sure if you’ve ever tried porting a custom ROM to such a device, I have. By the time Android was on the 3.11 kernel, I had a device still using kernel 2.6. It was insanity, half the functionality wasn’t working, we were reverse engineering and hacking together the rest, and still barely got anything working. It’s impossible to use a decade-old kernel with modern Android userland, yet that’s what you ask for.
But even for the self caused major version jam, the "get 2 years of support from upstream" is a heavy understatement and even after the n years of community LTS support ends, it's just the baseline you get for granted and you can diy more.
Due to Google’s pressure, it’s now 6 years.