An ambitious redesign of Android, known as Project Treble, separated the OS framework from device-specific low-level software (referred to as vendor implementation) using a clear, reliable vendor interface.
The basic idea behind project treble is to make OS updates faster by unbundling most system-level apps and services from the operating system so that they can be updated by the end user directly through the Play Store.
In the past, whenever a new Android version was released, phone manufacturers had to wait for the chipset vendors, such as Qualcomm, who provide the processors and other internal hardware components, to update the relevant modules. The phone manufacturer could only begin its part of the process once that effort was complete.
This involved merging the new Google software with its own interface modifications and feature enhancements, thoroughly testing everything, and getting everything ready for release. OEMs and vendors test Treble compatibility by booting a Generic System Image (GSI)—a pure stock build of Android from AOSP—and passing the Vendor Test Suite (VTS) and Compatibility Test Suite-on-Generic System Image (CTS-on-GSI).
For app developers, API consistency is important for the app to work on various devices. It can be verified by CTS (Compatibility Test Suite), and the developer APIs are specified in CDD (Compatibility Definition Document).
This is achieved by the introduction of a new vendor interface between the Android OS framework and the vendor implementation. The new vendor interface is validated by a Vendor Test Suite (VTS), analogous to the CTS, to ensure forward compatibility of the vendor implementation. Versioning is made mandatory for all stable HALs.
The goal is to make the new framework compatible with the old vendor implementation.
Android Framework will reside in the system partition, and Vendor HAL Implementation will be in a newly defined partition (vendor.img).
Hardware makers can implement a HAL, which is an abstraction layer with a standardized interface. Android can be indifferent to lower-level driver implementations because to HALs. You can add functionality by using a HAL without affecting or changing the higher-level system.
Devices launching after treble must use binderized HALs only.
Stable AIDL must be used by HALs that use AIDL to interact between hardware and framework components, such as those in vendor.img and system.img, respectively. However, there are no limitations on the IPC protocol that can be used to communicate between partitions, such as from one HAL to another.
Some of the information required by a VINTF object is obtained directly from the device.
The manifest file schema, framework manifest, and device manifest are all defined by manifests. Compatibility Matrixes define the schema for the compatibility matrix.
The static component of what the device may offer the framework is described in the device manifest.
The framework compatibility matrix describes what the Android framework anticipates from a specific device. The matrix is a static entity whose composition is decided manually during the creation of the upcoming Android framework version. The manifest describes the high-level services that the framework can offer the device.
The services that the vendor image expects from the framework are described in the device compatibility matrix. To guarantee that a device may get framework updates that are compatible with the device’s capabilities, these two pairs of manifests and matrices must be reconciled at OTA time. A compatibility matrix generally outlines what is required, whereas a manifest outlines what is offered.
The vendor-framework interface is described using the HAL interface definition language. The directory hardware/interfaces in contains all hardware interfaces .hal files
Use the hidl-gen programme to create the HAL files, then run the following commands: make hidl-gen –j64
The option to use AIDL for HALs in Android is now available with Android 11. As a result, sections of Android can be implemented without HIDL.
When a current AIDL interface’s owner decides to stabilise it, it can be used immediately. It used to be necessary to generate an exact replica of the interface in HIDL.
An AIDL interface requires two adjustments to be used between a system and a vendor:
• @VintfStability must be added as a comment to each type of declaration.
• The AIDL interface declaration must contain the word “Vintf.”
An AIDL service type which is visible to vendor code must have the hal_service_type attribute. Sepolicies are also modularized, and policy compatibility has been introduced by using various attributes.
Sepolicy flags after Treble
Thanks to DSU’s ability to swap between the current system image and the GSI with ease We can try GSI without running the danger of corrupting the existing system image.