The Epic Story of Android Updates
A good story needs to have an epic villain. And this story has one, its name — Android Fragmentation. Google has struggled with it since the early days of Android OS. It has changed tactics and tools, declared victory over it a few times but it still persists. So please let me entertain you with a history of Android Updates.
Fragmentation problem
I think the good place to start explaining Android Fragmentation is this picture that is familiar to every Android developer:
This picture shows how much people have old Android versions on their phones. As you can see — quite a lot of people do actually. That means developers need to support these old versions. And sometimes it means not using that latest features that latest Android has to offer.
Google for sure is aware of it. And unhappy application developers is just one part of the issue. They also want people to use latest features they have developed.
Even worse — people do not get latest security patches. Which means Android users with old phones are vulnerable and this allows Androids single competitor to advertise security and privacy as key features. Because (worst of all for Google) iOS does not have this issue. Most of people with iPhones in their pockets have either latest version of iOS installed or at least second to latest.
OS Updates
So why is this difference? Well, the answer lies with updates. After all, most people do not buy a new phone every year. And iPhones are much better with updates. And the reason for this is in the very key difference between Android and iOS: Open System vs Close System. Let me explain how it works…
What happens if Apple wants to update iOS? Apple creates an update and then sends it to devices. All that is left is for user to accept it.
What happens if Google wants to update Android? Well, here is the picture from Google to explain it:
You see the difference? iOS is a closed system that Apple controls completely. Nobody stands between Apple and the users. Android is a different story — it is an Open Source project. And Android phone is a result of a cooperation between multiple companies. Some of these companies produce chips, some of them produce phones, but all of them are involved in updating devices to the latest version of Android.
So in general this collaboration is a great thing, because it creates variety and facilitates innovation. Unfortunately it also makes update process so much more complicated.
Early attempts
As I’ve said, Google was always aware of this issue. And since it essentially lies in a cooperation between different companies that is how Google tried to address it at first. This attempt happened in 2011 and it was called “Android Update Alliance”. Essentially it was a pinky promise of some major Android vendors to bring new versions of Android to their devices fast. By 2012 it was already dead. Turns out business considerations beat pinky promises. And chip vendors and phone vendors want to sell new chips and new devices — not keep users happy with the old ones.
The second attempt came in 2016. And it was a bit less friendly. Essentially, Google created a rating that listed all device vendors and showed which updated their devices and which did not. The idea was probably to show users who is a “good” vendor and create competition this way. It’s hard to say whether this worked or not — Google never released these lists publicly.
But it is possible that around 2016 Google started to look at updates issue differently. If they couldn’t solve this with negotiations they decided to try fixing it as a bug. And in 2017 came this fix and it was called Project Treble. The first real blow to our villain.
Project Treble
Project Treble came out as a part of Android 8.0. And it was probably the single greatest example of refactoring in programming history. Google managed to re-factor the very foundations of Android OS, changed almost every of the OS sub-systems and create much better, modular architecture. And the most impressive thing — user didn’t even noticed, everything continued to work just as used to work before.
In this article I will only give an overview of Project Treble, without going into details. I think it actually deserves its own separate article, and maybe I’ll write it later. For now, here is the link to my talk about Project Treble from 2018.
Essentially, Project Treble was designed to take Silicon Manufacturers out of update picture. And while it does not sound too ambitious it actually required enormous development effort (some numbers that Google folks shared hint at 300 man-years of effort). And all this effort came down to this:
“Vendor” on this picture actually refers to Silicon Manufacturer. And while this picture is really simple it transfers the main idea — project Treble separated Android OS into Framework and BSP. BSP included low-level stuff, like drivers and HALs (Hardware Abstraction Layer). Framework part included higher level logic in System Services and Applications. Silicon vendor was now responsible for BSP updates, while Google and Device Manufacturer concentrated on Framework.
Two parts were separated by Vendor Interface. And the best thing about this interface — it was standardized, had versions and was backward-compatible. Which meant that device vendors didn’t have to wait for new BSP from silicon guys to start working on updating to newest Android.
So, overall it was a very impressive project technically. But did it actually help with making updates faster? The answer is yes, a bit. Here is another graph that Google released a year after Android Pie release.
As you can see it shows that Android Pie adoption rate is approximately 2 times faster than Android Oreo. And this has everything to do with Treble. You see, while Treble was released in Android 8, it didn’t actually help with upgrades to Android 8. It only helped with upgrades from Android 8. Here’s similar graph for Android 10 adoption:
As you can see it is even better with Android 10. 400 million users in less than a year. So, is that it, problem solved? Not really, and even these graphs show this if you look at them more closely:
1. The graphs are slightly deceptive because they show overall numbers and not percentages. And these numbers include both devices that are being upgraded from old versions and new devices that being bought having new Android version from the start. So the bigger number could also mean that more and more people buy Android phones now. And that is exactly what happens: there are 2.5 billion of active Android users today with 1.5 million daily activations.
2. The number of active users for the new OS really starts to pick up only after 100 days since its release. And the growth does not slow down even a year after. Which means that most people still have old versions of Android on their phone after release.
3. iOS is still a way ahead of Android in this area. If you put iOS on the same graph and replace total numbers with percentages, the growth will be 10 times faster than Android 10.
So, overall we can say that Project Treble made things better, but it didn’t fix Fragmentation completely. It was a step in the right direction and now Google needed the next step. And this next step came in 2019 with Android 10 — Project Mainline.
Project Mainline
Project Treble made Android OS architecture better, by making it more modular. And it separated areas of responsibility in Android OS code between Silicon Vendors and Device Manufacturers. Project Mainline continued with the same approach — modularity, and it took it one step further. Instead of splitting Android OS into two separate modules Google has separated it into many. Or rather it separated some of the Android system components into modules. Now it looked like this:
Project Mainline introduces a new concept to Android — Modularized System Component. This could practically be anything — application, service, library etc. What makes modules really special is that Google can update them directly through Google Play. Neither Silicon Vendors nor Device vendors stand in between Google and final user anymore.
So what kind of things Google decide to put into modules? In Android 10 it was divided into three categories, each serving specific purpose. Here is another picture from Google to describe this:
Security is the most obvious category. Google wants to be able to fix issues related to security ASAP. So they chose places in the OS that could be considered most critical in terms of security and turned them into modules.
Privacy is rather close to security in terms of purpose in my opinion. It is intended to help with protecting user data and privacy. Which is actually also a security concern. So in practice a differentiation between these two categories is rather forced. You can say that privacy modules are security modules directly related to permissions:
Consistency is the most interesting category in my opinion. First, it’s not immediately obvious why things like developer consistency and device stability are related to modular updates. These are the fine goals, but updating things faster does not necessarily help here that much. Second, most of the modules fall into this category. And almost all of the modules that were added in Android 11. Including the biggest of them all — Android Runtime.
The meaning of Consistency
Android Runtime deserves a separate mention. First of all it can’t be updated separately. So it is a module, but it’s only updated when the whole system updates. So why does it exist? Well, it carries a big part of Android core functionality, including (but not limited to) ART — Android Virtual Machine. Basically, without this module nothing works on Android now. If you update it without updating other OS you will break stuff.
And this is also the reason why Runtime and some other Consistency modules exist. In order to be compatible with multiple devices and each other modules can only rely on functionality from other modules. Runtime is probably the best example here — since everything in Android relies on functionality from this module.
But it’s not the only purpose of consistency modules. Consistency is actually a gift to all application developers as well. They now can be sure that certain APIs will work the same on all the devices from all the vendors. And most of modules introduced in Android 11 are like this — they just add new APIs that should work exactly the same on all devices and all Android versions.
And even that is not all. Modules are a rather powerful tool for Google to control device vendors. You see, separating parts of the OS into modules has two major consequences:
1. Google can update modules directly, without consulting device vendors
2. Device vendors can’t really touch the code inside these modules
And while the first consequence is probably the main reason for Project Mainline, the second one is also very useful for Google. Runtime module only exist for this second reason. Now Google can limit customizations of Android OS by the device vendors to certain areas making sure that some critical parts of OS work exactly the same for each vendor. This is consistency in a nutshell.
Another interesting thing to consider: while Project Mainline allows Google to update modules really fast it does not necessarily help with making overall system updates fast. After all they still come from device vendor.
Project Mainline is not designed to make OS updates faster. It is not designed to fix Android fragmentation. But it is designed to make fragmentation less critical by making updates less relevant.
And here lies the main surprise and the main beauty of the Project Mainline. It is essentially a technical workaround for organizational problem. Google realized they can’t make device vendors update devices faster and support them longer — this is against their interest. So instead Google removed most critical parts of Android OS from device vendors control and now update them directly. Personally I don’t think users will complain about this.
Conclusion
So, this wraps for now a story of how Google battled with Android Fragmentation. And it was more than just a struggle for faster updates. Google actually re-designed the very architecture of Android OS, created boundaries of responsibility between themselves, device manufacturers and silicon vendors. And in the end they not only made updates faster, they made the whole Fragmentation issue less relevant.
Is that it? Can we say that the story is complete and the villain is beaten? Not completely. It is definitely better than it was 3 years ago. But it’s still not as good as with iOS. And it never will be — Google can’t fix this as long as there are so many device brands.
However we should expect that the whole fragmentation issue will become less and less relevant. Project Mainline should help with that. After all why should users care what version of OS runs on their phones, as long as they get best possible security, privacy and all their favorite applications work?
Sources:
https://source.android.com/devices/architecture/modular-system
https://source.android.com/devices/architecture
https://android-developers.googleblog.com/2019/05/fresher-os-with-projects-treble-and-mainline.html
https://android-developers.googleblog.com/2020/07/accelerating-android-updates.html
About Author:
I have 6 years of experience developing firmware for different Android-based devices and I talked on a few tech conferences about Project Treble, Project Mainline and AOSP architecture. However I do not work for Google and do not have any inside information about Google plans for Android. I would be very glad to get comments from people interested in these topics. ( Here is my Twitter BTW)
If this article gets enough interest I will probably write separate ones on Project Treble and Project Mainline with more details. So if you liked this one please recommend it to others.
