One of the major criticisms of Android is fragmentation of software updates. To this day, many devices have to wait several months after their Google device counterparts just to receive the next major version of Android. For instance, Android Nougat was officially released in August of last year, but it has taken OEMs months on end to roll out Android 7.X to their users. As of this month, only approximately 7% of all Android devices are running Android Nougat. In an effort to combat the lengthy period of time between releasing new versions of Android and OEMs updating their devices, Google has announced the biggest change to the low-level system architecture of Android to date – Project Treble.
First, in order to understand what it is that Project Treble exactly does, it’s important for you to understand the general update process involved with each iteration of Android. The process can be summarized into approximately 5 or so steps, as such:
Google is generally very quick to release the source code of each new Android version, and even shares their code privately with some of their partners so they can get started to immediately update their code base. Google has no control over how long steps 4 and 5 take, but they’ve figured out a way to reduce the time spent during step 2. The team behind Android is “re-architecting” Android at a low-level in order to make it easier for silicon manufacturers to update and test their code.
To that end, Google is introducing what they’re called the Vendor Interface. This Vendor Interface is similar in function to the Compatibility Definition Document (CDD) and the Compatibility Test Suite (CTS), both of which ensure that OEMs know exactly what they need to implement in order for their devices to meet the requirements necessary to run Google Play Services on the latest version of Android. Google is modularizing Android so that the Android OS framework is kept separate from the device-specific, lower-level software written by the silicon manufacturers. The Vendor Interface is validated by the Vendor Test Suite (VTS), so silicon manufacturers know exactly what requirements need to be met in order for their chips to support booting Android.
The main benefit of this change is that device makers (OEMs) can now choose to update their phones by updating the Android OS framework without having to wait for silicon manufacturers to update their vendor implementation code. While this move, if made earlier, would unlikely have affected whether or not devices on the MSM8974 receive the Android 7.0 Nougat update (as the issue there stems from the CDD requiring either the Vulkan Graphics API or GLES 3.1, which IS something that OEMs would have to wait for silicon manufacturers to bring GPU support for in their source code), this move should still significantly reduce the time it takes for major Android updates to reach the hands of consumers.
By how much this move will reduce the update lag time, we can’t exactly predict. Microsoft solved this issue a long time ago with hardware abstraction of Windows drivers, so we’re hoping that this major low-level change brings Android somewhat closer to Windows in that vein. The new Project Treble architecture is already running on the Google Pixel and Pixel XL on the Android O Developer Preview, and the full documentation for the project will be made available with the launch of Android O later this summer.
Unfortunately, that means that for the vast majority of existing devices, you won’t be seeing the fruits of the Android team’s labor in Project Treble. It will be a few years before we can truly see whether or not this move has had a significant effect on reducing the time you have to wait to get the next flavor of Android. Nevertheless, this is an exciting development for Android fans, as it addresses one of the core problems with the operating system that many of us come to the XDA-Developers forums to address: software updates. We hope it lives up to the hype.