Hacker News new | ask | show | jobs
by djsumdog 3463 days ago
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:

http://penguindreams.org/blog/android-fragmentation/

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.

1 comments

You're spot on here.

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.