RedHat Enterprise Linux actually solved this with their kABI. This allows vendors to ship binary driver RPMs for kernels in the same RHEL major version (eg, RHEL 4, RHEL 5, etc). However, this entails a major effort on the part of RHEL, as it forces them to carefully backport improvements from upstream in a slow and careful way, so as to avoid breaking binary compatibility.
The RHEL kABI model was quite nice to deal with as a 3rd party NIC vendor (and you had to do it, even if you upstreamed your drivers, as they were frequently not backported to RHEL/Centos at a rapid clip, so RHEL customers would be using ancient buggy drivers unless you put together a driver RPM for them).
However, the source changes to support all the backports were something else entirely (which you needed if you wanted support for newly backported features). For a 10GbE driver that was roughly 2000 lines of C, I had a roughly 1000 line hand-made configure script, roughly 1/2 which was checks made necessary due to RHEL's backports. Checks that could have been a simple check to see what the linux kernel version was were complex spaghetti, trying to detect how many arguments some function took. This is because EVERY kernel was 2.6.18 for RHEL5, even if it had backports from 10 or more versions higher.
I'm guessing that Google felt that it was better to invest in building an OS they could control from the ground up, rather than hiring a building full of people to backport upstream patches in a binary compatible way.
Obviously, you can't just take .28, apply a fix, and call it .29... But you have to do something.. ideally something that indicates binary ABI compat with upstream .28, (so software vendors can just decide, your .28, you get .28 features.
Maybe something like SemVer needs a model for versioning of forks? (I'm not a SemVer fan or hater, it's just the best known effort in this area..)
And you're right, if you always build on the base version, then you have greater compat. However, you also loose out on the backported features, many of which were important for performance.
This is just an excuse. The reality is the manufacturers still have the mentality that once something is sold their responsibility ends. We see the exact same results on certain OS's that do have stable ABI's. You've probably made a transaction recently on a device that uses an old and unpatched version of windows CE.
I'm still shipping software for WinCE4.2 devices. They're supposed to be on their own little LAN segment, not bridged to the internet, with a border PC managing them. The upgrade path would almost certainly both an expensive nightmare and possibly infeasible - they have exactly enough Flash for the OS they shipped with.
It's really a cost-benefit tradeoff; all these software updates cost money. Who pays for that, under what circumstances, and why?
Not my experience. I have three hardware devices that worked on Windows, Linux and FreeBSD 5-10 years ago, and now only work on Windows and FreeBSD. (Amusingly enough one of them is a windows CE device)
Thus, with what you describe, the argument can be made that the Linux driver model doesn't appropriately take into consideration the incentives and needs of hardware manufacturers.
Isn't this a rampant GPL violation? Why do we put up with this?
We are about to lose the war for general purpose computing due to insufficient GPL enforcement.
Isn't this a rampant GPL violation?
For example, an OEM can bash out low quality code which is hard to maintain, secure in the knowledge that they'll only have to maintain it for the year or two that phone is getting updates, and it won't have to survive any big kernel updates or be compatible with anything that isn't on the phone.
Upstream, on the other hand, wants to maintain device support forever so they want good quality code that they can get through kernel updates with a minimum of fuss, and they can't accept anything that breaks existing code.
So upstream won't accept the OEM's shitty patch, and the OEM won't pay for the engineering time to make patches that upstream will accept.
(Of course, some OEMs absolutely do violate the GPL, and then there's also the issue of binary drivers and blobs that violate the spirit but not the letter.)
Interesting, wonder where this puts Android's Dalvik VM (is the VM called this too? I don't remember). Edit: Not sure what the JVM Dalvik is based on is licensed as though.
They do not want to piss of their corporate masters..
Who is "we"? As in, who will pay the lawyers?
At the moment, phones include all sorts of custom drivers for very specific versions of the hardware. The OEMs ought to send these upstream, but don't want to. You can't build your own kernel and upgrade without breaking all the binary-only drivers.
Android falls between two stools. Google own the userland but the OEMs are responsible for updates and the SOC manufacturers (mostly Qualcomm and Mediatek) are responsible for closed-source drivers. Arguably the cleanest and least achievable way out of this is trying to have an OS-only phone.