If you’ve read this column for long, you know I tend to be the skeptical sort — especially when it comes to talk of fixes for Android’s long-standing upgrade problem.
The reason is simple: I’ve tracked Android upgrades closely from the start, and I’ve seen numerous attempts to get device-makers to step up their game. There was the short-lived Android Update Alliance, announced to much fanfare at Google I/O 2011 and then never mentioned again. There was the launch of the Android preview program in 2014, which was hailed by many as being the long-awaited answer to slow and unreliable upgrades. And then there were the efforts to make the preview program more effective each subsequent year, with increasingly early previews and extended windows of time between the initial and final releases.
And yet, with each passing year, the majority of manufacturers’ performance with OS upgrades has only continued to get worse — to an almost comical degree, as of late.
So here we are, in 2018, with Android Pie fresh out of the oven — and again, we’re hearing talk about how this will be the year it all gets fixed. This time, the answer comes in the form of Project Treble, an ambitious effort to create a modular base for Android that separates the hardware-specific code — the bits related to the processor and other lower-level elements — from the rest of the operating system.
“Treble is one of a set of efforts going on in parallel that, together, we put under the umbrella of updatability — with the objective of resolving this version fragmentation issue that Android has,” explains Iliyan Malchev, a Google engineer and Project Treble architect who agreed to sit down for a frank discussion about Treble’s goals, the realistic impact it’s likely to have, and where things go from here.
My biggest question was simply how much difference Treble could realistically make. After all, while the notion of separating the lower-level code from the rest of the operating system is certainly sound, it still leaves the device-maker with a fair amount of work to prepare each new OS release for its devices. And historically, as we’ve established, most Android manufacturers haven’t exactly shown themselves to be motivated to move quickly on such tasks.
Project Treble and the Android upgrade process
To think about the impact Project Treble could have on the Android ecosystem, we first have to step back and take a moment to understand what, specifically, it accomplishes.
Years ago, HTC created an “Anatomy of an Android OS Update” chart that nicely sets the scene for what we’re seeing take shape today. As the chart shows, the first step in the upgrade process — after a new Android version is announced — actually occurs along two simultaneous paths: On one side, the phone-maker starts looking at the code and evaluating how it might fit in with its products. And at the same time, the chipset vendor assesses the release and, if it decides to support it, creates the necessary bits of code that allow it to run on its silicon — the heart of those devices.
It’s only when the chipset vendor finishes its work that the phone-maker is able to start integrating the software with its own additions and crafting the rollout-ready result.
“From that open-source push to an actual device that you hold in your hand, there’s a long road to be traveled,” Malchev says.
From Google’s perspective, an OS rollout is actually a three-stage process — starting first with Google, then progressing to the chipset vendor and finally to the phone-maker before reaching us, the users. In looking at those areas, Google realized it had an opportunity to streamline the process and make it more efficient.
And that’s where Treble began. With Oreo, Google laid the foundation by separating Android at the source level and creating a boundary between the main operating system and all that lower-level stuff. With Pie, Google filled in some missing pieces and worked closely with the chipset vendors to make sure they were ready for the new arrangement.
You can think of it like, well, a pie: In the past, all of Android was mixed together, and that meant each ingredient had to be updated and baked into the batter from scratch every single time an OS update came along. With Treble, all the hardware-specific elements exist as a crust — and that crust then remains in place for the life of a device. The phone-maker can then just focus on its part of the process without having to worry about waiting for someone else to provide and mix in an updated base with each new release.
“[The Android Open Source Project] is a building that is modular in nature,” Malchev says. “With Oreo and with P, we defined a firm foundation for that building — but because the building is extensible, we needed to enable silicon manufacturers to extend the foundation of the building as well.”
Pie + Treble = ?
All right — so back to my big question: Practically speaking, how much difference will all of this make?
Gauging by my discussion with Malchev, Google’s realistic goal seems to be more about making things at least a little bit better — lowering the amount of time, on some level, from when an Android version is released to when it appears on a typical handset — as opposed to implementing any sort of idealistic fix in which every manufacturer suddenly starts delivering day-one upgrades.
And all of that revolves around Treble’s improvements to that second phase of the process — the one that’s all about the chipset vendors.
“By working with the silicon manufacturers behind the scenes, we absorbed that lead time between [the open-source code drop] and what the OEMs get from companies like Qualcomm so that the OEMs can start working right away,” Malchev explains.
So how much time are we talking about being saved, exactly? In Malchev’s estimation, it’s about a quarter of a year — three months, give or take.
Let’s do a little math, then: By that explanation, if a phone-maker previously took seven months to get an Android release onto its current-gen flagship phone — as was the case with Samsung and its U.S.-based Galaxy S8 device for Oreo — with all other factors equal, it’d now take four months to get the update rolled out. If a phone-maker previously took just over three months — as was the case with HTC and its 2017 flagship for Oreo — it might be able to get the update out within a few weeks of its release.
Every manufacturer is not on equal footing
The important thing to remember is that there are still variables involved, and every manufacturer is not on equal footing. One variable is the level of effort required to implement a phone-maker’s higher-level modifications to Android — the visual changes and feature additions so many companies are fond of making. Google, in fact, sees that as the biggest variable to consider moving forward.
“The amount of time it’ll take an OEM to adapt Android to their own devices is a function of the amount of change they introduce into Android,” Malchev says.
But then we also can’t forget about the underlying factor of motivation. Plain and simple, most Android phone-makers don’t seem to view post-sales software support as a priority — and on a certain level, it’s tough to blame ’em.
Think about it: Despite the fact that they’re investing time and money in managing software upgrades, most Android manufacturers don’t make a dime of revenue directly off of those efforts. In fact, providing fast and frequent OS updates to existing devices arguably works against most phone-makers’ financial interests — as if anything, such timely and ongoing improvements will make you less likely to feel the need to upgrade to a new phone. As a company that makes the bulk of its money from ads and the services that support them, Google is the sole exception to this rule — and it’s probably no coincidence that it’s the sole Android-connected company to consistently make timely and reliable upgrades a priority.
Treble, for all its positives, doesn’t do anything to address that part of the equation. And remember, too: Even with Treble taking a chunk of labor out of the process, manufacturers like Samsung and LG still have a good bit of work to do to incorporate the numerous interface changes and feature additions they bring into the base Android software. The level of effort and resources involved is certainly less substantial than it was before, but it’s by no means negligible.
Still, Malchev believes the impact could be significant — and that Google is on the right path.
“Fragmentation is a difficult and messy problem, and it’s the result of organic growth,” he says. “The solution isn’t a magic wand, and it doesn’t present itself with the push of a button. It’s a lot of work — not only engineering-wise but also in working with our partners.”
Malchev also says Google has other efforts in place to work alongside Project Treble, though he wasn’t able to elaborate on most of them since they haven’t been publicly revealed yet. But he believes they’ll ultimately all work in tandem to create some meaningful momentum — a “snowball or avalanche effect,” as he puts it. And beyond that, he says there’s plenty more fine-tuning to be done before we see Project Treble operating at its full potential.
“It feels to me like we’ve built the machine,” Malchev tells me. “We’ve put the pieces together. Now, we need to run the process to completion.”
From the outside, all we can do is wait and see — with a close eye not only on the current flagship devices but also on the more easily overlooked previous-gen flagships and companies’ commitments to continuing support. As I’ve observed before, there’s every reason to be cautiously optimistic — but given the context around this, there’s also every reason to be at least a little bit skeptical.
One thing’s for sure: Any amount of improvement in this area can only be a positive. And based on how far most Android device-makers have fallen with their upgrade performance over the past several years, we can only hope that, at last, things will only go uphill from here.
Sign up for JR’s weekly newsletter to get more practical tips, personal recommendations, and plain-English perspective on the news that matters.
[Android Intelligence videos at Computerworld]