Pretty cheap if it ends up saving the Android ecosystem.
Android is maybe using 10% of the functionality in the linux kernel but is paying all the overhead and friction of maintaining a branch for each and every device.
I think google wants to heavily encapsulate the hardware vendors drivers and customizations and provide a stable API so google can pretty much update devices with on its own without much interaction with the hardware manufacturers. (Which are very complacent about their updating)
Why Linux kernel can support lots of CPU architectures in mainline tree but somehow requires to make a fork for each handset made by all these home appliance manufacturers? If you let all these vacuum cleaner companies to fork Fuschia, they'll fork it and put their "unique features" right into microkernel.
It's because all the stupid vendors refuse to share anything, and won't publish their sources for the various device drivers needed. So every time there's some new flash chip or whatever, there's a custom closed-source device driver for it which doesn't get mainlined or updated for newer kernel revisions, and devices with that chip are forever stuck on an ancient kernel version.
There's only two ways around this: 1) somehow force companies to open-source their driver code, or 2) have a static, unchanging (or at least very backwards-compatible) ABI for device drivers, and then just suffer with shoddy drivers written by vendors which cause all kinds of glitchy behavior, as Windows was infamous for for so many years.
This doesn't happen with the mainline tree because it's all open-source and gets debugged and inspected by others, but that just doesn't happen with the cellphones/Android.
> It's because all the stupid vendors refuse to share anything
I'm not going to defend the vendors (much). But it's not free to upstream your code. It's work. And I'd argue that it's an investment that will pay off, but you can't fault others much for seeing it differently.
I disagree. It's not free (usually) to upstream your code yourself, but there's nothing preventing you from publishing it for anyone to use. With a popular mobile phone, that'll very likely end up with someone else grabbing it and upstreaming it for you.
There's no guarantee some unpaid volunteer is going to do this kind of work for your company, but the chances are much higher if it's some kind of popular device.
For all your complaints about lack of a stable ABI, when you run Linux on a PC most of the hardware just works, most of it without out-of-tree drivers. (In some areas like graphics proprietary drivers give you a better experience, but even there typically there is some baseline support in tree.)
The reason this is possible on the PC and not on phones is because there are more standard hardware interfaces that don't exist in the ARM world. The lack of that is why the phone vendors need to do a lot of custom work.
It's also because ARM doesn't have a stable, standard BIOS the way x86 does. ARM is otherwise great, which is why people use it, but it has that one big downside. Every phone has a different hardware configuration, and getting that hardware working is always a fiddly bespoke job.
Not only Windows, the majority of operating systems are like that, even the old time commercial UNIXEs, only GNU/Linux forces an unstable driver ABI on developers.
Except that the "stable ABI" thing doesn't work in practice. Look at all the people who have to throw away perfectly good hardware every time a new Windows version comes out, because the hardware maker doesn't care about updating their drivers and just tells customers to buy a new version.
It works if it's architecturally designed to work. Mainframes and AS/400 does that. On System/38 (AS/400 predecessor), apps compiled down to a microcode against standardized interfaces. These got converted by special compilers to actual hardware. That's why apps written decades ago still run. You also got modern stuff as updates came in.
OpenVMS gave customers binary translation tools plus let clusters run with multiple, CPU architectures. That migration wasn't as painless but at least happened. Microsoft eventually applied this strategy at application level combined with OpenVMS's cross-language programming in the form of .NET CLR. It can work at much lower level as IBM showed in the 70's or 80's, though.
Android is maybe using 10% of the functionality in the linux kernel but is paying all the overhead and friction of maintaining a branch for each and every device.
I think google wants to heavily encapsulate the hardware vendors drivers and customizations and provide a stable API so google can pretty much update devices with on its own without much interaction with the hardware manufacturers. (Which are very complacent about their updating)