Manufacturers, Keep Your Hands Off My Zygote

As I often say, Android being open source is a double-edged sword.

(actually, I’m thinking that perhaps it is a more topologically-complex sword with lots and lots of edges, but I digress…)

Open source allows lots of people to get involved in creating Android devices, not limited to traditional form factors like phones. On the other hand, the ability for manufacturers to tinker with Android leads to compatibility problems. That in itself is not a problem… unless the manufacturer also wants app markets like the Play Store and Amazon AppStore for Android, and the compatibility problems have the potential to affect lots of apps.

One area of compatibility issues that has become more prominent is manufacturers messing with the zygote.

The zygote is a process, created when Android boots up, that contains the runtime (Dalvik or ART), framework classes and other JARs, and native libraries. When our app’s process is created, it is forked from the zygote. This is so Android can leverage the Linux kernel’s copy-on-write memory sharing, so the memory footprint of each of our processes is mostly limited to our own classes and other JARs, our own native libraries, and whatever we allocate on the heap.

Developers used to other environments will recognize the terms “DLL hell” and “JAR hell”. Any place where libraries are shared, changing those libraries affect all consumers of those libraries. The primary spot on Android where we get these effects is in the zygote, as our own classes and libraries are (usually) isolated per app.

Hence, when manufacturers change what is in the zygote, compared to what is normal for that version of Android, compatibility issues can result, such as:

• Samsung, on various 4.2 devices, put appcompat-v7 into the zygote, causing apps using the now-current appcompat-v7 to have conflicts

• LG, Samsung, and others, sometimes replace SQLite with newer versions, which probably will be OK, but that’s not assured

This is on top of Google’s under-the-surface and largely-undocumented zygote contents, such as the stripped-down edition of Legion of the Bouncy Castle that led to the development of Spongy Castle. That, at least, is fairly common across devices.

Sometimes, it would appear that manufacturers modify the zygote to have some library available in common for all their own apps. That is what I have to assume the rationale was for Samsung’s addition of appcompat-v7 to the zygote. This is simply sloppy, trading off the compatibility of countless apps to save a handful of KB of disk space.

Sometimes, the changes might be to address bug fixes that their own apps happen to trip over. This could be the reasoning behind the higher SQLite versions that LG and others have employed. That is certainly cool, though a bit more transparency would be helpful, and the fixes could still introduce compatibility problems.

Device manufacturers need to be very careful when altering what is in the zygote. Android is open, and device manufacturers have the freedom to alter what they want. Freedom to implement does not mean freedom from responsibility, though. Manufacturers that want apps from third-party developers need to ensure that the zygote the manufacturer uses is compatible with the zygote that third-party developers are expecting.

In other words, not all zygotes are created equal.