Despite Android's success the rest of the consumer Linux distributions chose to ignore it and continue on with what they were already doing. Trying to have them coordinate around what is succeeding is seemingly impossible.
It's a TiVo-ized spyware delivery platform, absolute riddled with (often non-removeable, often installed by entities other than the user) badware.
Android is an abject, dismal failure when it comes to very basic things like empowering users.
I disagree, unless you mean that they care about having there OS copy how UNIX worked 50 years ago.
>It's a TiVo-ized spyware delivery platform
Boiling things down to a pile of buzzwords is not productive especially when they aren't accurate.
"TiVo-ized": Android fully supports a user unlockable bootloader. Such a term doesn't even refer to the operating system, but to the device / bootloader, so it doesn't make sense to describe Android like that.
"spyware delivery": I assume this means that it includes a package manager that can install apps automatically. Several other Linux operating systems support that too. That isn't unique.
>absolute riddled with (often non-removeable, often installed by entities other than the user) badware
It is up to the vendor to pick what software they bundle with the OS. It's not inherent that "badware" has to be bundled.
Your criticisms of Android are not even with the operating system itself, but with downstream versions of it.
Android has made some very interesting technical decisions, and Linux workstations should implement something along pervasive sandboxing, for sure. The pretense that Android in itself is something anyone outside of large phone-manufacturing companies should (or are able to) deal with is a little silly.
I'm not sure I understand you here. What do you think other Linux distros should have done?
Collectively contributing to getting AOSP running on desktops, and then also working on backwards compatibility to be able to package their preexisting apps into Android apps. This would allow for there to be a common app platform for developers to target Linux with.
As a common target, AOSP isn't a very good one.
AOSP ran on desktops. (Maybe it still does, haven't tried it in a while.) It was still a mobile OS, though, so it wasn't good on the desktop, but it ran.
It also uses very old kernels.
Other than the kernel, the Android UI is completely different from conventional Linux. Any Gnome or Qt app would have to be completely rewritten to support it, and would probably have to run in the JVM.
Basically, if the Linux community followed your plan, they would have to commit a huge effort to port everything to what is essentially a completely different, incompatible OS in every respect except the kernel, and their reward would be to live in subservience to the whims of Google in supporting their product which Google themselves never had enough faith in to make it a proper desktop OS. It seems that the benefit does not justify the investment.
Which is why it would benefit from people who are trying to optimize it, and extend it to offer a good desktop experience.
>It also uses very old kernels.
It's based off the latest LTS release of the kernel.
>Any Gnome or Qt app would have to be completely rewritten to support it
Which is why my comment said that distros would work on backwards compatibility to avoid such expensive work of requiring a complete rewrite amd try to make it as seamless as possible.
>and would probably have to run in the JVM
Android does not use the JVM. It has ART, the Android Runtime, but you can still use native code.
>and their reward would be to live in subservience to the whims of Google in supporting their product which Google themselves never had enough faith in to make it a proper desktop OS
The benefit is being able to reap the fruits of the billions of dollars Google's is investing into the OS. Along with compatibility with a large amount of apps. As a bonus staple Linux applications may be able to installed to some of the billion existing Android devices today. Google may not have seen the benefit of supporting the desktop, but that's where smaller players can come in to play a role in trying to focus on more niche markets where there is less possible return.
Sure the windowing is limited, but it could be extended. I disagree that the IPC is limited though.
>Which means having access to all the ports and coding bespoke protocols. I don't think current android API allows for that.
It's still all open source. The distros could add new APIs to expose new capabilities.
Those exist already. With Debian, Alpine, Fedora,... you can put anything on top of the kernel in the userland. Android goes with a restricted version.
It's the same with MacOS. It's Unix, but with proprietary add-ons and systems. And lately, with more restrictions.
By restrictions do you mean having proper capability based security instead of letting all apps have access to everything? These restrictions are a good thing.
To be fair, Apple and Microsoft have also failed to try to unify desktop UI with mobile.
Linux has had other major dramas but not failures.
As far as I know Google has never accepted patches into Android, so everything has to be maintained outside the project in parallel, which helped kill it.
Google is not your friend, and they will not work with you. Android has diverged several times, and they break everyone else without caring.