tl;dr: Long rant about Android internals. I work with them. Quote: "The notable exception, of course, is Android, but that may well be the exception that prove

tl;dr: Long rant about Android internals. I work with them. Quote: "The notable exception, of course, is Android, but that may well be the exception that proves the rule: only a company with the financial resources of Google can hope to take on responsibility for that much code and hope to maintain it over the long term." If you start studying (or working with) the internals deep enough, you'll find out that Android is full of stupid technical decisions which cannot be sustainable in the long run. Having a Google-sized budget helps but there are some really weak links in there. I'll give two examples: the first one is Android's C library, Bionic. It seems like Android wanted to avoid using GNU libc just to avoid the need for having to upstream local changes due to GPL licensing in glibc. So they went ahead and wrote a friggin' C library, arguably the most peripheral and boring of all the software components in an operating system. And also one that's quite laborious to put together and maintain. It takes special character to do that. Ask Ulrich Drepper. You may argue that Android doesn't need all of glibc or that Bionic does it's job. From a customer perspective that may be true, but a customer does not see the libc anyway. But in reality, there's lots of hard work going on every day to ship products with Bionic. I've been watching that happen a lot recently. A lot of these issues seem to be related to threading and C++ ABI issues. The issues that glibc was struggling with 15 years ago. Another bad example is Android's 2d graphics library, Skia. It is the reason why Android home screen looks so crappy slow compared to certain competing products. It has a similar API to a lot of graphics packages that were popular in the 1990's. It includes bitmap blitters and so on. They have some optimizations to use NEON SIMD instructions, but it's inherently a software (CPU) graphics lib. The synchronous API offers no opportunity for hardware acceleration. I am under the impression that Skia would be going away from Android and that's a good thing. I promised two examples, but I'll give one for a bonus: Android's proprietary interprocess communication mechanism that's implemented in the kernel (can't remember it's name). It was designed to avoid a memcpy call when passing stuff from one process to another. That was a reasonable solution with slow uniprocessor computers of early 2000's but that ship has sailed. These days this kind of things are better done in the user space, like Dbus, which is used by most desktop (and some mobile) linux distros. Whoa, what a rant. But it only tells one thing: I'd much rather work with a GNU/Linux system than an Android one.