No, that stability is only promised for userland apps, not kernel-level stuff like drivers. In fact, there is no stable API/ABI for device drivers.
Now this mostly isn't a big issue on the desktop/x86 world, because most drivers are open source, except for some exceptions like certain Broadcom drivers and old nVidia drivers. nVidia used to be a massive headache to deal with because the driver would frequently break with kernel updates, but thankfully that's mostly a thing of the past after they released an open driver, relegating most of the proprietary code to their GSP firmware.
Also, PCs and the x86 platform in general are much more open and hacker-friendly, making it relatively easier to reverse-engineer drivers, so as a result we also have a good chunk of drivers maintained by the community.
So the lack of ABI/API stability isn't a big issue generally in the desktop space.
Now in the embedded/ARM space however, things are very different. Unfortunately due to the precedence set by Google, Apple and earlier mobile vendors, chipset vendors generally don't release their sources; even their architecture documentation is closely guarded and hard to obtain, never mind the sources. And the chipset themselves (like the camera/ISP) are tiny black boxes and hard to debug and reverse engineer. So unless this situation changes (ie, official Linux support from the manufacturers themselves), a simple unlocked bootloader means nothing.
This basically answers my question about dark weather in the future for all of this. If Google is standing on an issue of trusting their clients to be in the right bucket of profitable customer to get through agreements and NDAs on what they’re proving unless you’re a multi national juicy enterprise target they’re really not the people I want to deal with. I don’t know what kind of deal Google has but I suspect they finance a substantial amount of “evolutions” for their purposes through the blob device vendors.
Now this mostly isn't a big issue on the desktop/x86 world, because most drivers are open source, except for some exceptions like certain Broadcom drivers and old nVidia drivers. nVidia used to be a massive headache to deal with because the driver would frequently break with kernel updates, but thankfully that's mostly a thing of the past after they released an open driver, relegating most of the proprietary code to their GSP firmware.
Also, PCs and the x86 platform in general are much more open and hacker-friendly, making it relatively easier to reverse-engineer drivers, so as a result we also have a good chunk of drivers maintained by the community.
So the lack of ABI/API stability isn't a big issue generally in the desktop space.
Now in the embedded/ARM space however, things are very different. Unfortunately due to the precedence set by Google, Apple and earlier mobile vendors, chipset vendors generally don't release their sources; even their architecture documentation is closely guarded and hard to obtain, never mind the sources. And the chipset themselves (like the camera/ISP) are tiny black boxes and hard to debug and reverse engineer. So unless this situation changes (ie, official Linux support from the manufacturers themselves), a simple unlocked bootloader means nothing.