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-v7into the zygote, causing apps using the now-current
appcompat-v7to 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.
Stuck on an Android problem? Subscribers have access to live office hours chats with Mark Murphy, to help you work through your challenges!