Google’s Project Treble Modularizes Android so OEMs can Update Devices Faster

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.

---

Project Treble – Modularizing Android to Improve Software Updates

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:

1. AOSP Release – Google publishes the source code of the new Android release
2. Booting/Hardware Compatibility – Silicon manufacturers (Qualcomm, Samsung, Hisilicon, MediaTek, etc.) modify the source code so Android can boot on their chips, and all hardware on the chip functions as expected
3. OEM Modifications – This modified source is then given to device manufacturers (OEMS such as Samsung, LG, Huawei/Honor, OnePlus, HTC, etc.) so they can modify the source to include their own software.
4. QA/Testing – OEMs undergo testing phases of the software internally, and also test their software with their carrier partners.
5. General Release – the update is eventually made available to end users over several weeks through OTA updates

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.

---

Source: Android Developers Blog

from xda-developers http://ift.tt/2qBoQw3
via IFTTT

.