Understanding Project Treble and Android updates

The most common complaint about Android updates is that they are notoriously slow to release, historically speaking. Worse still, handset support is promptly re-evaluated once new models come along. Consumers have been complaining about this problem to OEMs and Google for years. Fortunately, the situation is changing following the arrival of Project Treble.

Project Treble was introduced as part of Android 8.0 Oreo and represents a major re-architecture for the OS framework. The initiative’s ultimate aim is to make updates faster and easier for OEMs to roll out to devices. Treble is arguably one of the biggest changes introduced to Android, but one that consumers won’t even notice as it works primarily behind the scenes. Here’s how it will affect the future of Android.

>> How Oreo is better than Nougat

Why the need for Project Treble?

In a word: fragmentation. It’s a criticism of Android that industry followers will be very familiar with, and it’s not unfounded. While iPhones receive major OS updates for three or four years, the most expensive Android smartphones are lucky to receive two, and lower cost models may never see an upgrade at all. Missing out on the latest features is unfortunate, but it’s the lack of security and increasing vulnerability of these older devices that is the real worry. Not just for users, but for Google also.

As smartphones take on an increasingly important role in using and securing our personal, financial, and otherwise important data, fixing security vulnerabilities is of utmost importance. As much flak as OEMs take for being slow with updates, there is a deeper reason for these delays that has, until now, made it difficult and expensive to support devices in the long term.

The slow update problem has to do with the way that Android software layers communicate with underlying phone hardware. In order for applications to run on a CPU or use a camera, the OS has to talk to connected hardware via a hardware abstraction layer (HAL). This is important if, for example, you want third-party apps from the Play Store to work with any phone’s camera – HALs are designed to be low-level driver-agnostic. Below this is the Linux kernel, which handles the hardware specific communication between the HAL and the exact components in the phone. It has to be compiled depending on your handset’s specific hardware.

The problem with 7.0 Nougat and older version of Android, is that there’s no separation between the vendor’s low level hardware code and the higher level AOSP operating system code that Google maintains. In Android 7.x and earlier, no formal vendor interfaces existed, meaning that device manufacturers had to update large portions of the Android code with each update. This includes waiting on hardware vendors, such as SoC manufacturers, to provide their code to hook hardware into the new OS.

Unfortunately, Android didn’t used to have much in the way of plug-and-play compatibility with low level hardware; code had to be heavily tailored. This takes a considerable amount of time, testing, and cost on the part of silicon vendors and OEMs. Project Treble solves this problem by separating the Android OS Framework from the vendor hardware code implementations, therefore allowing Google and OEMs to update the OS without having to reconfigure all the the lower level hardware parts.

OEMs will still want to introduce their own proprietary hardware and software features, which will add to development and testing time. And OEMs will still have to take extra time incorporating their unique features into the AOSP from Google after Project Treble’s introduction. Treble simply reduces the amount of work that needs to be done by third parties, particularly SoC vendors, who provide much of the hardware code.

How updates work after Oreo

It’s important to reiterate that Android uses the Linux kernel under the hood. A kernel is the part of an operating system which handles input/output and computer instructions from the application layer, essentially allowing the application software to communicate with the hardware. To make changes to the way Android handles this communication is to make some notable changes to the way the Linux kernel operates.

To solve the hardware abstraction layer issue, Android 8.0 Oreo and later version like Android 9.0 Pie formalize the division between hardware subsystems like audio or camera, and their clients on the software side. These new formal divisions specify the interface between a HAL and its users. There are now around 60 formal interfaces for various hardware components, known as HIDLs.

The goal of a HIDL is to allow the framework to be replaced without having to rebuild HALs. HALs will be built by vendors or SoC makers and put in a /vendor partition on the device, enabling the framework, in its own partition, to be replaced with an over-the-air update (OTA) without recompiling the HALs. To update devices running earlier versions of Android to Android O, developers can wrap both conventional and legacy HALs in a new HIDL interface too.

Equally as important, Linux kernel long-term support has recently been extended from 2 to 6 years for Project Treble. This means that major fixes to the kernel are no longer missed over a device’s longer-term life cycle. Previously a device would at best see a year’s worth of support left by the time it hit the market.

As you can see, the switch to Project Treble requires a little bit of work on the hardware vendor side too, as the way the vendor implementation is programmed to expose the hardware to Android is different to previous OS versions. Once this revised vendor implementation is on the device though, manufacturers can choose to deliver a new Android release to consumers by just updating the Android OS framework, without any reworking required from the silicon manufacturers.

An interesting note in Google’s documentation is that “Project Treble will be coming to all new devices launched with Android O and beyond.” This implies phones coming to Oreo from Nougat won’t necessarily be Treble compliant. For example, the OnePlus 5T, a phone that ships with Nougat, isn’t Treble compatible with its update to Oreo. Neither are Samsung’s Galaxy S8 and S8 Plus. Meanwhile, the original Pixels do support Treble following their update to Oreo.

Devices shipping with Oreo, Pie, and future versions out-of-the-box have to fully support Treble, as OEMs will be coding the vendor implementation in this way from the get-go and are now obliged to have a working version of AOSP on their hardware. As of Android 8.0, the new vendor interface is validated by a Vendor Test Suite (VTS), to ensure that the updated OS is compatible with the existing hardware setup.

Project Treble doesn’t necessarily mean that all handsets will see updates instantaneously, as Google is not handling them directly. OEMs are still free to tweak and skin the OS, as well as embed their own software into the Android OS release. So there’s still going to be some time taken for OEMs to build and test their own particular take on Android. However, by taking silicon vendors out of the equation, these updates should still be faster and software should be much easier to apply across numerous devices.

Implications of Project Treble

From a user perspective, OS updates will be delivered in exactly the same way as they are now. Vendors will still be able to push OTA updates, which you can download at leisure in the background without having to do anything more than tap a prompt. Hopefully, we’ll end up seeing them appear a little quicker than before and for longer into a device’s lifetime.

Project Treble has some interesting implications for the revival of the custom ROM scene too, as there’s likely to be less work required to get software and hardware playing nicely. It could take just days, rather than weeks or months, to port AOSP to a device that supports Treble. XDA community members are already excited about the prospects. Developer NewDroid went as far as to call this a breakthrough, after booting Oreo on the Mate 9, which hadn’t even seen a single custom Nougat ROM. Other developers have also already shown off a single system image capable of booting on different devices with different processors.

The prospect is that we may be edging closer to a time where Android software can be easily ported across a range of devices, much like how Windows can run on a huge range of hardware configurations with minimal effort. But that’s not the goal of Treble at the moment.

Closing thoughts

Project Treble sounds very promising, but it’s important to understand that it has limitations. First, this isn’t Google taking over updates. Product manufacturers like Samsung, HUAWEI, and LG are still responsible for compiling and rolling out updates, and they won’t be anywhere near as fast as Google is with the Pixels. Treble is instead an OS structure optimization designed to speed up rollouts from manufacturers. Google has done its part, now it is up to the OEMs.

Second, only handsets with Android 8.0 Oreo and 9.0 Pie installed out of the box must support Project Treble. Phones that upgrade to Oreo from Nougat don’t have to fully support Treble, though OEMs can choose to if they wish. We’ll have to pay close attention to which manufacturers say what as they roll out their Oreo upgrades. It’s also unlikely that custom ROMs will be able to introduce Treble to many older devices, as lower level hardware access isn’t open source.

If you’re looking for a phone with Treble support, currently Google’s Pixel series, the Essential Phone, and HUAWEI’s, Mate 10 and P20 Pro, Samsung’s Galaxy S9, and basically all of the 2018 flagship phones are all boasting support. Mid-range devices shipping with Oreo also make the cut. The Android 9.0 Pie beta appeared on a number of handsets thanks to Treble and final releases for many models are scheduled to appear before the end of 2018.