The really bad problem with android is IMHO not one google produces directly (maybe indirectly by not working with the mainstream-kernel; but certainly not willingly): It's phone-vendors patching drivers (and the rest of the system with it) and not merging them upstream.
Now you get hundreds of phones which have no recent android-distribution on them. Right now, the only hope for those affected are things like Cyanogen-mod (A big "thank you" to them, by the way), which in effect provides a community-distribution for certain android-phones.
Forking the kernel (and making their own distribution) actually puts google into the place of responsibility. Things the kernel-community would have done have to be done by google now. And I think google should step up, get all those driver-patches from all the device-manufacturers involved and make an android-distribution which runs on _all_ phones.
The minimum I would expect is for google to provide a kernel (and its sources, in a form which can be compiled with minimum fuss -- with "make menuconfig; make", just as the mainline kernel) which would run on all the devices.
This relates to this weeks "Forking ARM" article by Thomas Gleixner, but is actually yet another different problem plaguing the ARM platform. No hardware discoverability, and no standard BIOS+ACPI thingy(thank god) to bring uniformity. The kernel developers have been working on a solution and came up with device trees, although those might one day be part of the problem (just like BIOSes, ACPI and EFI).
forking vendors
Posted Jun 7, 2011 16:52 UTC (Tue) by swetland (subscriber, #63414)
[Link]
Well, all credit due to JBQ who works his butt off, but from the system/kernel team's perspective, we'd *love* to get closer to mainline and have things more standardized. It's certainly not easy.