This month I’m honored to share an article written by my friend Karim Yaghmour, one of the world’s leading experts on the Linux and Android platforms, about Treble, a major revision to Android’s architecture.  The article is in-depth enough for an experienced engineer to appreciate, yet explains the details in simple enough language that most people with a basic grasp of engineering can gain valuable insight from.  Since there’s a lot to talk about with transitioning to Treble, we’ll release the article in multiple parts over the course of the next month.

At its core, Treble’s introduction into Android 8 is a way for Google to have better control over the different hardware variations used across Android products released by different manufacturers.  The intention is to make upgrading old hardware to new versions of Android more streamlined so that manufacturers have an easier time pushing system updates to end users, much like Apple does when there’s a new version of iOS (the iPhone operating system) comes out.

Karim has published multiple books that are used in universities and companies worldwide that teach engineers the intricacies of the different layers of Android and the Linux kernel.  Karim’s firm has been hired by governments, Fortune 500 companies, and tier 1 brands for consulting and educating these groups about key decisions regarding Android programming and how to use this technology.

Karim is based in Quebec, Canada and has been an active member of the open source community for nearly 20 years (he’s very old 😉 ).  He’s someone I use as a personal reference when I have questions about Android software and he’s available for helping other companies with their needs related to building custom Android platforms and functionality.  You can learn more about Karim’s work and his company at www.opersys.com.

A happy new year and warm regards from all of us at Hatch.

Benjamin Dolgin-Gardner, Founder
__________________________________________________________________

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

Android is a very fast moving target, with major releases coming out at least once a year and minor releases often following within months.  Initially pegged in a tight competition against Apple over its iPhone line of products but, more recently, increasingly diversifying Android’s capabilities and features to cover an ever-expanding range of product types, Google has continued to push Android into new territory with every new release.  

Generally, Google’s additions and updates cover look-and-feel, user experience, hardware capabilities, new APIs, and all manors of the user and developer-visible changes.  Though most changes grow the system organically, some have been fairly substantial like, for instance, the introduction of a new app permission model in 6.x/Marshmallow.  

Still, for the most part, few changes, if any, had any significant impact on the internals of the Android platform.  Since its very early days, in fact, and up until the 7.x/Nougat series, the way Android operated internally and, most importantly, how it supported hardware remained mostly constant.  That all changed with the release of 8.x/Oreo and its introduction of Project Treble.

Treble represents a major departure from how Android works internally in several important areas, especially with regards to hardware support.  Before 8.x/Oreo, for example, device developers and manufacturers were mostly free to modify the internals of the Android stack in any way they liked.  Insofar as they preserved the app development API’s consistency and apps could be tested to run as if on reference Google devices, as attested to by running the Compatibility Test Suite (CTS), then the device was still GMS certifiable as an Android device.

This is no longer as simple starting with 8.x/Oreo, at least if GMS certification is even remotely entertained or desirable.  One of the reasons for that is the introduction of the new Vendor Test Suite (VTS) which checks whether the hardware support implementations follows Google’s specifications.  As we will see, however, Treble is a lot more than just VTS, despite it being one of the more salient aspects from a business perspective.  Because even if certification isn’t on your radar, Treble is a break from the past with regards to the system’s internals.

In this series of posts, we’ll take a closer look at Treble, starting with Google’s motivations for introducing such an invasive change into the core of its foremost OS.  Understanding the underlying goals will help us decipher the rationale behind many changes that, on the face of it, seem to significantly ratchet up the system’s complexity and reduce integrators’ ability to customized Android.  

With that in hand, we’ll go over the specific changes introduced by Treble in 8.x/Oreo.  While this could easily turn into a technical deep dive, we’ll mainly focus on the overall architectural impact of those changes in addition to contrasting them with “business as usual” in 7.x/Nougat and before.  We’ll then cover the implications such changes have for custom device manufacturers and close with recommendations.

Motivations for Treble

It has become a yearly ritual at the Apple Worldwide Developer Conference (WWDC).  Apple’s CEO’s keynote introduces a new iOS version and loudly trumpets the percentage of older Apple devices that run the latest version.  In the 2017 run of the grand Apple mass, Tim Cook proudly announced to the faithful that 86% of iPhone customers run iOS 10 (the then latest version).  As he put it: “This blows away the other platforms”.

Apple in fact keeps an up-to-date live pie chart showing the percentage of devices running each version of iOS.  At the time of this writing, it shows that 65% are running iOS 11 (the latest version), 28% are running iOS 10 (latest minus 1), and only 7% are running earlier versions.  The vast majority of users are therefore running at worst the previous release.

Google too maintains its own live pie chart for Android.  The picture it draws is vastly different, however.  At the time of this writing, only 0.7% of Android devices are running 8.x/Oreo (the latest version), 26% are running 7.x/Nougat (latest minus 1), 28.6% are running 6.x/Marshmallow (latest minus 2), 26% are running 5.x/Lollipop (latest minus 3), 13% are running 4.4/KitKat (latest minus 4), and 7% are at least 5 versions behind.  In short, almost 75% of Android users haven’t even gotten to running the previous release.

Ponder this for a moment.  Despite all of Google’s efforts at releasing a bleeding edge OS that can arguably be described as beating iOS to the finish line on a number of key fronts when it’s released and including in it all the latest security fixes, it literally takes years before the majority of Android users get their hands on devices that have those features and fixes; by which point equivalent functionality may have already found its way into older iOS devices.  

At the time of this writing, 8.x/Oreo was released last August, 5 months ago.  Yet less than 1% of Android devices are running that version.  In contrast, iOS 11 which was released one month after 8.x/Oreo, runs on 65% of Apple devices.  Surely Cook’s annual jab at Android at WWDC must hit a nerve in Mountain View.

That, however, is not the official story that you will hear from Google regarding the inception of project Treble.  Neither can I honestly claim that I have any inside knowledge that would lead me to believe that that’s the actual logic that played out at Google prompting project Treble.

Google does not, in fact, typically discuss any of the rationales, be they business or technical, underlying its decisions with regards to Android’s future.  Outsiders are often left best-guessing the decisions that are eventually reflected in features and additions found in new Android releases.

 The stark contrast between the percentage of Apple devices running the latest versions versus Android devices as a prime motivator for Treble is, therefore, this author’s reading of the tea leaves.  Still, Google’s own documentation would tend to validate such a reading.

The opening phrase that introduces Treble in Google’s own documentation states: “The Android 8.0 release includes Project Treble, a major re-architect of the Android OS framework designed to make it easier, faster, and less costly for manufacturers to update devices to a new version of Android.”  In a single phrase, Google eloquently states the problem it’s facing and the key impediments to solving it.  

First, Google essentially admits Android upgrades are an issue; the numbers we saw earlier are laid bare for anyone to independently come to the same conclusion.  Above all, however, Google diplomatically outlines the forces at play behind this issue and thereby provides us with a foundation to understand the logic behind their technical decisions.  

Apart from implying that Android updates are difficult, long and costly, Google’s opening puts the finger on the one aspect that most differentiates its work from Apple’s: unlike Apple, Google doesn’t directly manufacture the vast majority of Android devices on the market.

Indeed, Google makes its OS available for any manufacturer to take and integrate into their hardware and sell to consumers.  The only part where Google intervenes is in ensuring that those devices are certified before they can receive Google’s own proprietary applications and be allowed to be branded as “Android” devices (i.e. GMS certification).  

Google cannot force any of the manufacturers using Android to actually update users’ devices to the latest version.  It can only create incentives for this to happen and facilitate that work in as much as possible.  The facilitation part covers Google’s opening line’s stated goal of making updates “easier, faster, and less costly”.  The incentive aspect, on the other hand, is not stated outright in the Treble documentation, it’s left as an exercise to the reader.  

Here’s the key passage from the same Treble introduction page: “To ensure forward compatibility of vendor implementations, the new vendor interface is validated by the Vendor Test Suite (VTS), which is analogous to the Compatibility Test Suite (CTS).”  This is the arm twisting part.  In short, if you want your device to be certifiable against any given version of Android, you must make sure that you conform to the rules laid down by Treble which will, therefore, make your device’s upgrades “easier, faster, and less costly.”

In layman’s terms, Google is playing the good cop-bad cop routine.  They’re essentially telling manufacturers: “Look, we understand that upgrading your Android devices has historically been difficult, long and costly.  We’ve taken that into account and built mechanisms to make it simpler, shorter and less expensive.  But you’re going to have to play along.  

Because if you don’t play along, we won’t certify your devices any longer.”  It can do this because of the one statistic that you won’t hear Cook mention at WWDC, which is that according to research firm IDC Android’s smartphone OS market share is 85%; iOS effectively occupying the remaining 15%.  In short, Android is the only game in town for non-Apple manufacturers and to play with the cool kids’ manufacturers will have to make-do with Treble moving forward.

You can almost picture it.  In 4 to 5 years, Google’s CEO will be able to take the stage at Google I/O and claim that the vast majority of Android users are now running the latest or near-latest version of Android, much like Apple’s CEO has been doing.  Google’s accomplishment will have been far more impressive though as it will have been able to come up with a set of technical solutions backed by a certification requirement that ensures that Android users the world around can enjoy the features Google puts out in new Android releases in near-real-time, much like Apple users enjoy today, despite Google relying mostly on hardware manufactured by 3rd parties.  All thanks to Treble.

In part II, we’ll look at how Treble modifies Android’s release flow. 

About The Author:
Karim Yaghmour is a 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-’90s, he pioneered the world of Linux tracing with the Linux Trace Toolkit.