If you are a regular reader of the pieces I pen on here and, maybe, elsewhere, then you are likely familiar with one grudge I usually have against everyone doing anything Android-related over the last 8 years: updates. Android updates are a pain in all the wrong places. It’s been 6 years since this rant.
Every year, Google announces a new version of Android. That may be a point release, as happens months after every major release or, if we go back a few years, the point update becomes the “major” release that year. Or it may be a major release as was the case in 2011 when Android 4.0, Ice Cream Sandwich, debuted and forever changed Android as we would know it for a few more years before the radical Material Design redesign that came with Android 5.0 Lollipop.
Glorious and fundamental as all those updates have been, my constant ranting about updates (and I am not alone in this) is usually because for the most part, getting an Android OS upgrade usually means buying a new phone. Yes, that. In a world where Apple disables a bunch of new features that obviously can’t run on dated hardware so that it can avail updates for devices as old as 4 years, twice the length of time that longest-running software-related contractual obligations for providing updates by any Android device maker last.
Over the years, Google has made effort after effort of addressing all these concerns and pushing its partners (the device makers) to avail updates to as many of the devices they make as possible in the shortest time possible. Such efforts have included Google starting to work with device makers and app developers months before releasing a new version of Android. As such, we now have a preview phase where we get to experience a new version of Android long before it’s made available to all eligible devices. By doing this, Google hoped to kill two birds with one stone: get device makers to test and be ready to roll out updates when it goes public with a new operating system (OS) build and get app developers onboard so that they have their apps optimized for the new version of the mobile OS by launch day.
There’s also other initiatives that have come along to help Google help device makers get the latest versions of Android out of the door: first it was the Android One and now there is the Android Go project to give the movement some further momentum.
To be honest, all these efforts have mostly ended up nowhere. While it is too early to pass any judgement on Android Go, it is very clear that Android One failed in its mission hence why Google had to re-purpose and repackage it. Letting device makers play with upcoming software builds long before they go public has not helped matters. It still takes half a year, at least, for most recent top-of-the-line Android devices to receive the latest versions of Android. For everything else that lacks a Nokia logo at the back, the wait times range from as much as a year to a year and a half, for the lucky ones. For the unfortunate ones, which translates to hundreds of millions of devices every year, how about never receiving the newest versions of Android? Brutal, yeah, but that’s the world we live in.
The slow rate at which Android device makers release updates has mainly been attributed to the extensive customizations each Android device maker does in a bid to differentiate their product offering as well as add more features. While there’s no agreement on whether all that is necessary, I am one of the few people that appreciate the few device makers that do these customizations not for the sake of just doing them either to be different or to copy others (Apple) but to offer real value to users. There have been such useful features as the infrared blasters that various devices makers have included in their devices, sound customization, camera features… name them.
The only problem arises when there’s a new software that upgrades the underlying framework on which all those great or bad additions (S Voice, Bixby, OPPO’s ColorOS blocking the ability to change launchers and others all fall here) are built on. For the device maker who also worked on this software, the challenge is usually to find a way of delivering this update without breaking the user experience. That is easier said than done and most usually end up compromising and not delivering the update at all.
For us in Kenya, we are lucky that our local mobile network operators like Safaricom, Telkom Kenya and Airtel Kenya, don’t go ahead and further customize the devices they sell us as exclusive. The most they can go is usually a network lock, not tampering with the software. Think the Orange Kaduda Smart or the Safaricom Neon Kicka. As such, as Kenyans, the last thing we have to worry about is having carriers stand in the way of us and receiving updates, like they do in most developed markets.
Enter Project Treble
With Android Oreo, Google gave the efforts to make sure end users get updates another boost by introducing something called Project Treble and in keeping up with its usual naming scheme of specific initiatives aimed at making Android better. We’ve previously had Project Butter, Project Svelte, among others. Whereas Project Butter did away with all the infamous stutters and lagging and made the experience buttery smooth in Android Jelly Bean going forward, Project Svelte was the closest to our subject matter today. It was one of the building blocks of what would become a near-eternal quest to make Android universal.
Project Svelte was meant to make it easier to run the world’s most popular mobile operating system on devices with as little as 512MB RAM. That Android Go exists today is testament to just how it never got nowhere. Yet when it launched, it was famously referred to as “Google’s silver bullet to fix Android fragmentation”.
Project Svelte never got anywhere near exorcising the ghosts of Android’s infamous fragmentation problem so here we are with another “project”, Treble.
Project Treble’s mission is simple: separate the core parts of the operating system from the rest to make it easy to update.
The way Android was structured before Oreo was such that it was not easy to separate the core parts of the OS from the rest. As such, any updates meant having to rework the entire thing, a daunting task that not many device makers were willing to undertake given the amount of resources required (manpower and time).
In a typical Android smartphone, there’s the hardware and the software, The hardware are the tangible parts. Things you can see and touch. Like the display, the camera module… And even things that you can’t see and touch but you could anyway if you opened up the phone. Like the processor and the memory, for instance. Then there’s the software, which is the operating system in question complete with any modifications done by device makers and the apps installed by users. These are intangible. Much as you can “see” and interact with the software through the software interface, it pretty much exists in abstraction. For any action by the user to be meaningful, like say, taking a photo, the hardware, which is the image sensor and its related parts, must communicate with the software.
Depending on the nature of the camera app in question (a system app i.e. one that came pre-installed on the phone or a third party app), the operating system is able to understand the nature of the request and then queue it for action through the processing module (the processor). All of this happens so fast that it appears seamless. However, a lot of things take place behind the scenes to facilitate your selfie cravings. Google’s software has to be able to communicate with your phone’s hardware as made by the device maker, to the very lowest level. Normally, that is where the problem arises.
Every other time Google releases an update for the software, the device maker has to test it to make sure that it is able to talk to the hardware it has in place. Not just that, it has to make sure that the newly updated software is able to operate within the environment it has gone ahead and created as well as those that are sourced from third parties (like makers of mobile radios – for 3G and 4G – processors and graphics cards). In instances where the updated software breaks either the device maker’s own modifications or is not compatible with some of its own hardware or that supplied by partners like chip makers, then it has find ways of harmonizing things before rolling out the update. Otherwise, things will break when it does so. Additionally, this testing phase to make sure everything works can drag on resulting in delayed updates.
With Project Treble, what Google has done is to separate the core Android operating system bits from this whole other mess that I have described. That way, it is possible to push updates to this specific partition while not interfering with everything else.
So, ideally, device makers can update any of their devices as soon as Google provides an update and they have streamlined their in-house software customization, if any, without having to worry about other aspects like one the ones I have described above. The end result is supposed to be that every other device out there receives devices first and fast.
Due to the nature of the process and what is required, a lot of the devices that existed as Google introduced Project Treble to the world simply are not able to support as they were not made with it in mind. What I mean by this is that they do not have the core Android framework, which is what Google updates, separated from the other hardware-centred layers. Newer devices, however, are being built with this in mind. Device makers are even obliged by Google to support Treble on devices they’re updating to Android Oreo.
Devices currently on sale in the Kenyan market like the Nokia 7 Plus, the Huawei Mate 9, the Xiaomi Mi A1 and others have confirmed official support for Project Treble.
It should be noted that as much as Project Treble is being implemented in good faith, a device supporting it does not automatically guarantee its users faster updates. There still needs to be some level of commitment from the device maker to do so even as the process has been simplified. Also, the usual software update terms, which dictate the length within which particular devices are at least eligible for updates from their makers, stay in place. That means, after a certain period users can expect to stay in the update cold, however eligible their devices are. Unless, of course, they are willing to take the high road and join the root and ROM brigade (a very dangerous outfit 🙂 ).
I did not want to turn this explainer into a mini Computer Science class so if you want to go more in-depth than this, Robert Triggs at Android Authority has got you covered.