Karim Yaghmour, CEO Opersys inc. (www.opersys.com)

Treble and the Android release flow

Why have Android updates been generally difficult, long and expensive?  What are the specific issues with older releases that made such updates so difficult?  And how does Treble attempt to solve this? Let’s take a closer look at the processes at play and the architecture choices involved.

Traditional Android release flow

In its announcement blog for Treble, Google provided a diagram that illustrates quite well how an Android release goes from being released by Google to making it into users’ hands:

When Google releases a new version of Android (#1), it needs to go through a number of steps before it gets to users.  First, silicon vendors take that version and create a BSP (#2).  This BSP is then used by device manufactures to create a phone SKU (#3).  This device is then certified for use by carriers (#4).  The latter can then finally sell those devices to users (#5).

Prior to Treble, the process had to practically start anew to update an existing Android device when a subsequent release of Android was made.  Here’s a diagram that illustrates how Android’s internals were tightly coupled together prior to Treble:

In short, Google’s updates to the OS framework were not sufficient for an update to occur.  Instead, there were several vendor-dependent changes that needed to be adapted as well; “vendor” here including any of silicon vendor, device manufacturer and/or carrier.

Trying to update such a tightly-integrating system through the workflow outlined above created a situation with all sorts of perverse counter-incentives.  Let’s assume for the sake of example that you had purchased a Samsung device in 2014 from Verizon that was based on the then-latest Qualcommn chipset running Android 4.4/KitKat.  In November 2014, Google released 5.x/Lollipop.  For there to have been an update for your device, a number of stars needed to align.  First there must have been an incentive for Qualcomm to port 5.x/Lollipop to the chip that was included in your phone.  Usually that would’ve meant that Qualcomm was still selling that chip and that it hadn’t moved on its efforts to supporting newer chips.  So let’s say Qualcomm had created a new BSP for that chip.  Samsung must have then had an incentive to take that BSP and create a new Android image for that device that you bought several months prior (i.e. it’s not making any new money from you for this update despite the work required).  Usually that incentive is that it’s still selling that device and it’s one of its prominent products.  Verizon had to then take it from there and continue the work (here’s an older article explaining why carriers were sometimes hold-outs in the update game), possibly because it was still one of its hot products as well.

Now ask yourself what would’ve happened when Google released 6.x/Marshmallow a year later in October 2015.  Would Qualcomm still have been selling that chip you had?  Would Samsung still be banking on that older model of yours?  Would the carrier be interested in supporting an OTA for a 2 year old device?  Surely at some point one of those players would’ve expected you to buy a new phone or, at the very least, strongly hoped so.  In fact it’s very likely you would’ve been incentivised along the way to do just that.  Nevertheless, Google’s numbers don’t lie.  It looks like a lot of people keep using those older devices much longer than any of the players in the chain between the user and Google would’ve preferred they did.

Treble’s update flow

While rolling out a new Android release on a brand new device will likely continue to go through the same workflow outlined earlier, Google’s objective with Treble is to ensure that updates follow a much different workflow.  In effect, while Google’s own documentation doesn’t show this diagram, Treble’s purpose is to try to impose this workflow for updates:

Basically, Google wants to cut out as many middle-men as possible during an update.  To achieve this, Android’s architecture is modified to add a new Google-defined and Google-maintained layer called the “Vendor Interface” underneath the Android framework:

By forcing every player along the release cycle to conform to this Vendor Interface – by way of requiring VTS for certification –, Android OS framework updates can be made without requiring the involvement of any of the vendors.  More to the point, we get a new internals paradigm:

In practice, this means that newer Android framework releases will be able to recognize and work with older vendor interface releases.  To use the previous handset example, let’s say you buy a new Android phone from Samsung in 2018 that was initially released on 8.x/Oreo (i.e. it’s not a phone that ever had 7.x/Nougat on it nor any previous release) based on whatever chipset is most recent from Qualcomm at that time from Verizon.  Thus far, the work involved in getting that Android release on that device followed the same 5-step flow outlined earlier.  Next year, however, when Google possibly releases 9.x/“P”, that release will likely still support the 8.x/Oreo vendor interface – in addition to likely sporting a new vendor interface version of its own – thereby allowing it to run straight on your device without the involvement of any of the original intermediaries.  That, at least, is the theory.  We’ll have to wait for the release of 9.x/“P” to see how it actually works out in reality.  Still, in theory, insofar as 10.x/“Q”, 11.x/“R”, 12.x/“S” and so on continue to support the 8.x/Oreo vendor interface, this device you buy this year will be able to seamlessly receive all those updates without requiring any of the traditional intermediaries to participate in a meaningful fashion.

The onus is then on Google to continue maintaining older vendor interface versions inside the framework as long as possible.  It should be clear by now, though, that it has obvious incentives to do so.  Again, picture Google’s CEO at Google I/O in a few years once the effects of this new architecture start falling into focus.

In part III we’ll start looking inside the changes made by Treble to the Android stack.

Acknowledgements:
Several diagrams used here are distributed by Google under CC-BY-SA license.

About The Author:
Karim Yaghmour is part serial entrepreneur, part unrepentant geek. He’s most widely know for his O’Reilly books: “Building Embedded Linux Systems” and “Embedded Android”. As an active member of the open source community since the mid-90’s, he pioneered the world of Linux tracing with the Linux Trace Toolkit.