google offered to buy Cyanogen.
(http://arstechnica.com/gadgets/2014/10/google-reportedly-tri...)
Also, recall that Cyanogen (the company, not the mod) said that they were going to "put a bullet in Google's head". I bet Google has tried to offer support to them and Cyanogen turned it down.
What you mean by "usable"? Vanilla Android is really usable nowadays (I have a Nexus 6P with Android 7.1.1, non-rooted with locked bootloader since I don't really root nowadays). CyanogenMod nowadays is more important for their support to multiple hardware then the customization from AOSP per see. This is especially true since for those who really want mods, things like Xposed Framework offers much more customization.
"Vanilla Android" (from the AOSP) doesn't pass the Compatibility Test Suite (CTS) nowadays, so according to Google's Android trademark rules shouldn't be called Android. Some of the "Core" apps simply don't work at all.
Don't confuse what Google publish at the AOSP with what they ship on the Nexus/Pixel devices: they're increasingly different, with AOSP increasingly dysfunctional. Heck, the initial release of Android 7 for the 5X/6P at the AOSP wouldn't even compile because it had closed source compile-time dependencies.
I know that AOSP isn't the same Android running in Nexus. However I have an Android tablet that I used to run AOSP (nowadays is running CyanogenMod, probably needs to change it to LineageOS). The core experience is exactly the same once you install GApps (at least the minimum necessary to run Play Store).
And no, I really don't need anything that CM brings (I only switched from AOSP to CM because it was better supported on my tablet, CM actually had a developer while the AOSP guy was simply pulling the changes from the CM developer).
Supporting many devices is a double-edged sword. I feel what Google wanted for their AOSP code is to not support tens of different devices to make the code move fast. Part of what made CM valuable, I feel, was really the changes that made it compatible with so many devices. So CM would have to remain CM for the devices support, not for the features of the ROM.
I have never understood the desire to have 1 Homogeneous Platform with no variety, no customization, no personality.
To have a large corporate overlord dictating how I use the device I "bought"
I see these same statements in the Linux Desktop world where everyone bitches about how All the Distro's are different, and how the Arch way is different from the Debian Way, and different from Red Hat, Canonical etc.
That is what I LIKE about Linux, that is what is LIKE about Android.
If i wanted a Corporate Overlord I would use an Apple or Microsoft commercial garbage
It'd be nice if you could just customize Android on ARM and have lots of different spin-offs in the same way you have various x86/64 and PPC Linux distros. I wrote about this:
The problem is with all these ARM boards. As other comments have pointed out, vendors have tons of binary blobs and shim layers that link them to the kernel. Nvidia/AMD do this too with their video drivers, as well as Intel/Broadcom/Atheros with their Wi-Fi/BT chips. The difference on the PC platform is that it's standardized enough that you can run any kernel/distro on almost any x86/64 board and it will boot and give you a console.
Android vendor kernels are patched to hell, duct tape, just enough crap to get to production style software. They don't submit patches upstream because their code is often junk. ARM SoC are also all incredibly different.
You can download x86/64 versions of Debian, Gentoo, Void, Slackware, whatever and it will at a minimum boot on any PC hardware made in the past few years (probably even a Pentium if you use a 32-bit distro). Not all your hardware will work, but it will at least boot. ARM makes no similar guarantees. Cellphones don't support device trees, and even if they did the whole device tree system is a mess of its own.
Google has ultimate control over all vendors with the OHA. They can mandate standard kernels and drivers across devices. They won't though. There's simply too much money in requiring people to replace devices every two years.
To also add, some (most!) vendors make dirty hacks to the kernel source, as they maintain it as a standalone tree for the most-part.
Wired the headphone jack the wrong way around? Don't bother with a new PCB revision, as deadlines are too tight, and getting things perfect seems to have no place; just hack at the driver code in a messy way and change the outputs! It's not like you're ever going to really keep the device supported for a long time anyway!
So you get layered hacks - the SoC maker adds their own hacks because their production cycles are so short. Then the OEM gets the SoC and integrates it with their board, and due to their short development cycle, hacks around any issues they have too. End result is unmaintainable spaghetti of hacks and tweaks, which mainline wouldn't touch in a million years.
If the vendor is patching kernel they probably must release their patches and proprietary drivers as GPL requires (regarding drivers they could avoid this by moving important parts into userspace).
There's two things that happen: one is adding more hacks in the kernel that while required to be released under the GPL (and sometimes are, sometimes aren't!) are never going to reach the mainline kernel in a thousand years because they are way too hacky.
The other is creating userspace blobs that get passed void* from the kernel containing (kernel) internal data structures. The problem then comes about when the kernel changes those data structures.
Because there's a very finite amount of open-source developer time in the world, and expending it all over the same territory over and over is foolish.
Developer time is not a finite resource. People contribute to projects that they are passionate about. Fragmentation can encourage engagement. It's not like unpaid xfce and kde developers would start kernel hacking if everyone converged on gnome, even if it would benefit the ecosystem. Many would pursue other hobbies.
Developer time is finite. Fact. There's no basis to question this. There's limited numbers of people on the planet and they have limited time. Sure, the number of contributors can grow (we haven't reached peak-developer numbers), but it actually grows more with success than with failure. Fragmentation is fine if there's actually enough resources for at least one project to really succeed. In most cases, and probably in the case of community-centered free/libre/open Android variants, there's a shortage of developer time and a real worry about it being fragmented into multiple projects instead of being more cooperative.
Volunteer open source developers are not interchangeable cogs ('resources') to be redeployed across projects at will by anyone except themselves - they are volunteers and work on stuff they are passionate about.
The F/OSS 'community' has some of the most entitled folk on this blue planet - I'm yet to hear anyone suggest pet shelter volunteers work together on a mega-shelter instead of "wasting effort on duplicate roles".
This request shows a deep misunderstanding of the issue at heart and of the history between Google and Cyanogen.
For one, Cyanogen has always refused to follow Google's guide lines and license terms. This is both what makes Cyanogen appealing to a small minority of users and also why there is absolutely zero chances why Google would ever fund this kind of effort.
Supporting the upstream is different. One cannot simply download AOSP and install it on your phone, however custom roms provide something you can actually download and install. Google deliberately does not improve the AOSP base applications because they don't want people using their proprietary apps. Google mainly supports AOSP because they can get more people hooked on google services with it than they loose from things like Kindle.
So directly supporting an easy, installable downstream with bells-and-whistles like cyanogenmod would be a serious threat to google.
With a little bit of careful adjustment to settings, you can disable all Google services on a Nexus device. It takes a little effort, but it can be done - unrooted and unmodified.
interesting. I'm aware that to quell anticompetitive accusations, google allows removal of many google apps and disabling of many services. But I believe the Google Play Services is deeply embedded in the google stock rom such that it can't be safely disabled in entirety.
Maybe make it a law that company needs to maintain certain level device security via software update for N years for internet connected devices.
Or they are required to release those device's source code to (and pay for) the "communities" for the maintain the security updates.
If they don't do it, they are responsible to damage caused by those devices because of security issue or the customer's loss of data/privacy due to hacking by 3rd parties.
Similar to recent case where "food processor" company is liable if the blade is cracked into pieces into the processed food after a few years.