And whenever they broke that API, that actually happened — suddenly updates stopped being usable by your system.

Also, be aware that ARM has nothing to enumerate devices, has no BISO or UEFI. An OS image will only ever work on a single device.

As I detailed in another comment in this thread, the issue is this collision of the Linux concept of mainlining everything, short support windows, manufacturers that can't update drivers for every microchip they sell all the time, and Google and OEMs somewhere in there.

It's always been a clusterfuck, Google didn't create it, but they sure made it worse.

Microsoft provided drivers for the standard PC hardware that was in my 2006 Core Duo Mac Mini and Windows 7 recognized all of my hardware - usb, sound, graphics, Bluetooth, Ethernet etc.

Microsoft goes out of its way to provide drivers for the most popular PC hardware. Mac OS is Unix (i.e certified by the Open Grouo) and doesn't have that problem.

Edit Rant:

But why are printer drivers still a thing? Apple introduced AirPrint for iOS 4 back in 2010 and for MacOS a few years later. I never have to worry about printer drivers when I update my OS. New printers bought in 2017 work perfectly with my 7 year old iPad without having to worry about drivers.

Have you looked at the unimaginable amount of crap a typical Windows printer driver forces upon you? It's not just the driver, it's usually also a stripped down license of some image editor, an "update agent" (because Windows 7 does not have an "app store" or a centralized driver distribution that does not phone home like Windows Update does and often enough carries fossilized drivers only), a toolbar for multifunction printers, a watcher that nags you to buy new original cartridges, a scanner agent because there is still no standard for scanning without drivers, much less so over network or cross platform, a selection of adware... and God help you if you have printers or MFDs from different vendors.

The only way to not have this ridiculous mess is buying enterprise printers - for example, the Z2100 plotter drivers are 4MB for Windows, and 16MB for the manager app, while the Photosmart printer driver can only be had as a part of a 145MB download, there is no such thing as a "driver only" package in the consumer space. In enterprise environments (or small offices) the situation sucks even more because you can't really deploy them via GPO, you have to extract the drivers by hand.

And for most of the consumer gear from HP it's the same: even for really old stuff you can find new tanks/cartridges, drivers for new and old OSes and I've yet to see a HP printer fail in a way I could not fix myself with a service manual.

My response to anything HP that wasn't good-sized obviously-business-targeted printers became "I can probably make that work, but it's going to cost you more in my time fiddling around with it than just getting a more appropriate printer."

That and apart from an initial few months of unstable GFX drivers, was utterly solid.

On a side-note, I believe Core Duo2's was the last Intel chips to not include any form of inbuilt `management` silicon and as such,still favoured by some paranoid/security prudent types.

Yes. I go out of my way to run a clean crap free Windows PC. Even going as far as either buying from the business line of laptops or buying from the Microsoft store. But the minute I install a printer driver....

It's even worse for people like my parents, they search online for printer driver and usually end up downloading crapware from a third party site unaffiliated with the printer manufacture.

Won't help as much if you want color though, particularly inkjet color.

And for your parents, see if they're putting the current year on searches - on Bing and DDG that ends (or did end recently) in much worse results because the original sites often don't include dates but malicious ones have all the same keywords plus the year. In my recent experience adding the year meant > 90% malware results on the first page.

Google was much better about this a month or two back.

Regardless of stable driver API or not, it is up to the OEMs to make it happen, if they actually cared about it.

I am pretty negative about Project Treble, it won't change anything, because only Oreo devices have it (0.3% currently) and OEMs are still expected to be the ones pushing the updates.

Usually I hear that sort of thing and think somebody isn't being creative enough with fallback behaviors for when the feature isn't there, but I guess it would depend heavily on what the feature is.

Isn’t that the purpose of a device tree?

It is primarily to allow the drivers linked in the kernel to detect whether they should load and try to talk to hardware. It doesn't replace bus enumeration when running on totally unknown hardware.

I own Crappy unupdated Android one of. And the drivers use the Linux kernel. Last I checked, they need to release source for their drivers.

So where is it? And why can't we upstream those patches and "fix" android?

The OEM never releases the source.

And courts have decided that it's not enough if you have some contributions to the kernel yourself or are a user to force them to release it, you have to have made significant contributions to force them to release it via the courts.

And Torvalds and the major kernel maintainers all refuse to enforce the GPL, and actively campaign against doing so.

Two questions: why? and why use the GPL if you’re not going to enforce it?

On most phones, there are zero external kernel modules loaded. The SoC vendor bakes it all into the ketnel, and the OEM gets the kernel as a blob. Which means all of it is subject to the GPL.

But this was my main area of attack. You compiled the drivers directly into the kernel. Making it all GPL. Now, as a strict reading, I have to have the device to make the request. That's not difficult. Ive phones from a lot of US named companies.

I just want the rights enumerated in the GPL as granted to end users. I'm no kernel maintainer. Just a cranky person who wants the GPL enforced as any license.

Yeah, it turns out it’s not that easily enforcable. There are still court cases going on, but the current legal situation seems to be that unless you’ve contributed significant code to the kernel, you have no legal leg to stand on.

Because the OEM is simply saying "yes, we violated the GPL, and infringed the copyright of the developers", but the only ones who could sue against that would be devs that contributed significant amounts of code.

It's a lot of work, who is supposed to do that?

Some bits of the N900 kernel are still in the process of being upstreamed afaik.

The source helps little since it's just opaque garbage with little to no meaning.

Mobile phones and other embedded devices have none of this.

First, Google didn't design anything. They were looking for partners for their OS and these partners used their existing design. The first HTCs were almost identical between their Android and Windows Mobile versions.

Second, there are reasons why the embedded systems do not have them. Apart from increased complexity (bad for the designer and manufacturer), increased energy consumption (bad for consumer, and being a competitive disadvantage too), very few of both, embedded devices manufacturers and customers, even count on using other software than the one supplied. From the point of view, there every cent of saved costs on the device makes millions in margin, that would be wasted money.

Microsoft basically strongarmed the PC vendors - they either did what Microsoft said, or didn't ship Windows with their wares. Windows, which was the only game in the town, if you wanted to sell PCs.

Google didn't have such luxury when they started with Android. They needed to be everyone possible to be with them onboard and the "lets throw out everything you have and design new hardware from scratch" doesn't make for a good start.

In mobile, Microsoft also reused Qualcomm's reference design. But contrary to Google, they used ONLY Qualcomm's design, that's why their system looks united. All the WP phones are basically the same board.

However, that does not mean you will get an open device now. When was the hardware openness so important, that it played a major role in purchase decision at statistically significant rate?

For 99,999% of people, it doesn't. They want an appliance that works out of the box, without bothering with alternate firmwares. So that's what they are getting.

There's no motivation to put UEFI and PCI into the hardware, just like there wasn't 10-15-20 years ago, when the first designs were made.

On the other hand, iOS updates do cause problems and then it's the carriers, who scramble to modify their networks to make iPhones work (remember when Brits didn't have mobile data for a few days after an update?). They would not do it for Xiaomi or Sony.

What was indeed the insult on top of the injury - the WM devices were all Qualcomm Snapdragon devices. They were never so varied as Android devices are.

However, the part about them all being the same Snapdragon devices with slightly different cases, cameras, etc. is still true. Microsoft doesn't have to solve how to make a release for Exynos, Kirin or Tegra devices.

That being said, this was only kindasorta a good thing, because it didn't always have working third party drivers attached. My old Samsung ATIV SE was super glitchy, particularly in the touchscreen department, when I upgraded my phone absent Samsung's blessing.

But it was one more place Microsoft kinda demonstrated even their mobile OS builds were more or less hardware independent, which is a huge contrast from Android.