The issue is that Treble simply shifts the compatibility issues from on from one layer (kernel) to another (Android HAL). There's still a compatibility horizon, because newer Android systems will eventually want to use newer kernel features and HAL APIs which were not present on ancient HALs which have been abandoned by the vendor.
And even if the OS could theoretically maintain backwards compatibility with older HAL APIs for 10 years, in practice the System + HAL combinations which aren't fully tested tend to break for various unforeseen reasons, making it unwise to push OS updates to devices which aren't fully supported by their vendor.
I don't think it is intentional. Linux development is very pragmatic, they just want to have freedom to refactor anything without caring about stable kernel APIs.
> Support a stable kernel API probably wouldn't be that expensive
If anyone wants to read the Linux developers’ explanation directly, here it is:
https://www.kernel.org/doc/html/latest/process/stable-api-no...
And Qualcomm is probably very, very happy with this arrangement. They can put a gazillion devs to maintain their BSPs using any means possible, but a small 2nd tier SoC fabbless don't.
I bet a lot of drivers are just interfacing with a standard serial line which could be done in the stable user space and then exposing the next layer through something like FUSE.
If I understand treble correctly that’s close to what Android is doing, where each HAL can be done in userspace?
Also as far as I remember (I might be wrong) the google HAL isn't a abstraction/redirection in the low level kernel module layer it lives on a higher abstraction level and was meant to make the amount of ways braking less but never planed to add abstractions on top of which you could build a graphics driver or CPU support (which doesn't only affect drivers but potential also kernel compiler time conditional compilations).
When asked about it most kernel developers point to closed-door negotiations that are being kept confidential. Usually also saying "trust us, we know what we are doing, we'll get more source opened our way".
Those who actually try to enforce GPL publically are ignored or shunned, e.g. Harald Welte/LaForge of gpl-violations.org
This is a conscious and opinionated strategy on the part of Linux, as an effort to make the cost of keeping drivers closed-source high and the cost of kernel refactoring low. It also has... disadvantages, in the form of a massive wasteland of only-supported-once snapshot-in-time devices. I am sure this comment thread will happy expound on this in great and painful detail.
Secondly, there was an entire effort by Google called "Project Treble" to build a stable Android HAL/ABI over the top of these unstable kernel interfaces. Unfortunately it would/will require essentially an Android-specific rewrite from vendors in order to fully implement, so many drivers are not yet operating in this model.