In addition to the device-specific ROMS, Google has introduced so-called GSIs, Generic System Images with Project Treble in Android 8 or Oreo. The compatibility of the images to the individual devices is to be guaranteed by the Google Android certification starting with Android 8. Google has introduced these new system images to address the update delays caused by different manufacturers. For this purpose, the system was divided into clear layers that can be updated in a modular fashion. One layer is the system, another is the so-called vendor implementation. The vendor implementation comprises the firmware that makes the hardware functional and at the same time provides a framework with interfaces that the system can access in a standardized way.
Unlike the device specific ROM, not all parts of the system need to be updated when a new Android version is released. This allows vendor implementation and system to be updated independently.
At the same time, this type of system image provides a new opportunity for the custom ROM scene. Developers can compile a new version of their system, which can then be flashed on any smartphone that supports Treble, provided the vendor implementation is bug-free. System updates therefore no longer need to be compiled for each device individually. As long as a phone is tested with the Vendor Test Suite and certified according to the CDD, it is Treble compatible.
Unless we get to talk to a professional Android core developer who deals with code compilation such as Generic System Images for Treble compatible smartphones. In my limited understanding here is the possible potential and issues involved with GSIs that were introduced with Project Treble.
I see a lot of benefits. One of the primary mileage I cannot ignore is that one ROM works for a variety of devices or smartphones. Custom ROMs are no longer tied to a specific device with its device trees and fixes. Instead, the developer can fully focus on the system without having to work on the hardware implementation. This is already given by the Google certification.
Under certain circumstances, a bug fix could solve problems with many devices in a single shot without going through individual patches for a plethora of devices. For instance, you could fix a flashlight malfunction on a device from a specific vendor with Qualcomm chipset ending up writing a fix for a whole range of Snapdragon chipset powered devices from same or more vendors. Equally important, especially for the custom ROM scene is that the user interface and thus the user experience can be changed quickly and easily with Android Studio.
Furthermore, it is good that GSIs now offer the possibility to install GSIs and updates on even the most “strange” devices, regardless of the manufacturer, once the devices are Project Treble certified. This would give the user the freedom to fully focus on the hardware specifications of devices when buying them. All bloatware and the overloaded and resource-intensive Android user interfaces could be replaced by GSIs on every cell phone. In addition, not only devices with Qualcomm chipsets, but devices with any chipset could be replaced by GSIs and can be supported.
From what I have heard one of the biggest challenge is the vendor implementation, i.e. the realization and functionality of the basic hardware functions. Google’s CDDs only specify what needs to be implemented to certify a device, not how it should be implemented. For many things Google has not yet specified, for example fingerprint sensors that are built in under the screen. In this respect, every manufacturer does it in his own way. One quick or easy fix could be some sort of common system images, with which the entire hardware implementation is subject to Google standards and only the User experience is left to the manufacturers. I am not sure if Google is willing to burden itself or is ready to take the responsibility as of yet.
Either ways, Project Treble packed a punch and gave hope for better support and upgrades for devices with Project Treble certification. But smartphone market is a very fast moving and it is getting hard to predict the absolute future.
Another point regarding durability is the contamination of operating systems by pre-installed software such as apps and Android interfaces, which can be very resource-hungry and slow down the smartphone. GSIs could free the devices from this and thus enable better performance for longer. Smartphones may not need to be replaced as quickly because their performance is maintained longer.
Standard & Treble-Updates
The following comparison of the conventional update process with the new Project Treble should clarify the simplifications by Project Treble. In the conventional update process, Google first released an Android Open Source Project version for each new Android version. Together with the correspondingly following CDD, chip manufacturers like Qualcomm or Samsung could adapt the integration of the chipsets to ensure compatibility to the new Android version. This concerns especially the firmware level.
The adapted and modified source codes were then passed on to the smartphone manufacturers, who could incorporate them into their versions of the Android software (Samsung Touch Wiz, Miui, Emui etc) and tailor them to the respective devices. This was followed by an internal test phase in which network providers were also involved. After successful completion, the new Android version was then delivered to the end users.
Google usually ships new Android versions for its devices quickly, as it is at the beginning of the chain. Other manufacturers usually need half a year to a whole year for this. With the update to Oreo, Google has introduced its Project Treble, which means standardization of the process and hardware connection. The chipset manufacturers’ source code is separated from the actual Android version, the interfaces between them are standardized. The first steps of the update process can thus be done in parallel and faster. At the same time as the Oreo update, Google has provided a new test suite to check the compatibility of the device and the new software version. This vendor test suite is intended to ensure that the so-called vendor interface with its new interfaces and the hardware meet the requirements of the CDD and that Google certification is possible. These profound changes to the Android framework are to be gradually expanded.
