Last I checked a big issue was Qualcomm doens't support their SoC for very long so manufactures have to tweak each devices 'tree' (it's unique kernel and drivers) for each kernel update.
The whole point of project treble was to disconnect the Android version from the kernel version so that manufactures could keep using the existing kernel and drivers and would only have to recustomize the new OSI to their liking.
Turns out a lot of device manufactures still don't see much value in providing timely updates since the general public doesn't even know what version their currently running and are just as likely to hate an update than like it.
Personally, I feel Google's sluggishness to enforce update policies or change how Android works is out of fear that Samsung will break completely and launch their own app store and not have the Play Store, or rather Play Services which is what Google needs if they want to power many of their online platforms (where do you think Google map road conditions come from?, Or that feature that shows how busy restaurants are?). Without play services on every Android device, Android looses it's profitability.
I think you may be mixing up “ABI” and “API”. If you change internal kernel APIs, you’d break a lot of code and have to go in and fix it. If you change the ABI, you just have to recompile. The ABI does change pretty often and as a rule of thumb there is no effort to keep it stable, the way you would if you were writing a shared library (which ideally has both a stable API and ABI). Drivers in the kernel are not broken because they are recompiled with the rest of the kernel. Kernel modules from different kernel versions ARE broken and this is why we have DKMS.
But just to talk about what happens here—Apple is the only developer of the XNU kernel, and they have a fairly short list of iOS SKUs in the history of iOS, and only a small portion of those get iOS 13 support—something like 12 iPhone models. So the support for all of these devices is right on the mainline kernel development tree.
This is not how Android development works. You generally have a bunch of different manufacturers, who get a team of engineers to get a fork of the Linux kernel working on each device, and then they drop it and move on to the next one. There will be various binary blobs involved, and integrating the changes back upstream or downstream ends up being a pain.
And just to return to the original point, the Linux kernel developers are actively hostile to any attempts to make the kernel ABI stable enough for binary blob drivers to work. This is not a question about whether it is technically possible.
In contrast, Qualcomm gives the OEMs a copy the custom Linux kernel that works with their SoC[1]. The OEMs then use that source to build their kernel, probably making minimal changes to it. Once Qualcomm stops selling that SoC, they stop releasing updates to their custom kernel because there's no pressure from OEMs to keep it patched.
[1] eg. https://github.com/MiCode/Xiaomi_Kernel_OpenSource/tree/ceph...
Hasn't Samsung already tried that with Tizen (and didn't do well), which was also put on its Gear smartwatches?
I'd expect it to be technically possible, and for Google not too difficult, to pick a version of the Linux kernel module ABI to define as the Android module ABI, and then for newer kernels with newer kernel module ABIs add an adapter layer that can translate from the old ABI to the new ABI.
— Greg Kroah-Hartman <greg@kroah.com>
https://www.kernel.org/doc/html/latest/process/stable-api-no...
And fuck the billions of people with CVEd kernels because of it; they're just collateral damage, right? /sigh/
Classical Linux drivers are considered legacy on Trebelized devices.
https://source.android.com/devices/architecture/hal#hal-modu...
The big problem is that in spite of having a standard ABI, Google does not require OEMs to actually push updates, so everything stands as before for consumers, while OEMs have even lower development costs.
I can't think of any open source software vendor that is able to force its customers to accept strict policies, because forking is always an option.
Windows updates work for years because manufacturers maintain Windows drivers for their hardware. The Android ecosystem is more like the Linux desktop one -- each manufacturer sells a different Android distribution with their own custom stuff mixed in.
Linux doesn't. So OS updates leave behind old drivers.
So manufacturers don't have to do anything for their drivers to continue working on Windows, and it is often the case that updates will stop shortly after hardware is released.
— Greg Kroah-Hartman <greg@kroah.com>
https://www.kernel.org/doc/html/latest/process/stable-api-no...
This is a pretty weak argument against doing the right thing by taking control of system updates. Even stock Android devices stop getting updates very quickly because of how tightly coupled to the hardware drivers Android is. It doesn't have to be that way.
Amazon is doing okay with cheap tablets but their phone was a failure.
This would mean that you'd have to commit to a stable ABI for device drivers, forever.
The only phone I know which fits this description is the Librem 5. Unfortunately it would currently be a lot cheaper to just buy second hand android phones every 2 years than to buy one of these but hopefully they can get the price down later.
5 years of support for a driver ABI seems achievable though. Especially for basic things like proximity sensors, touch screens, buttons etc.
How often is the ABI for a button going to change?