Android Pie and Project Treble: Assessing Google’s grand upgrade fix

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.

. Exclusive extras await!]

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.

Take this mobile device management course from PluralSight and learn how to secure devices in your company without degrading the user experience. ]

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.

Android Update ProcessHTC

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.

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.