What is Android Treble?

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.

Need for Android Treble

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).

Android Treble Implementation

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.

Treble Changes - Verified Boot

Treble Changes - Build System

Android Framework will reside in the system partition, and Vendor HAL Implementation will be in a newly defined partition (vendor.img).

Treble Changes - Binderized HAL

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.

Treble Changes - Compatibility Checks

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.”

Treble Changes - Sepolicies

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 before Treble

Sepolicy flags after Treble

In Android 8.0, SELinux policy is divided into platform and vendor components in order to allow independent platform/vendor policy updates while maintaining compatibility

Sepolicy flags after Android 11

The system_ext policy and product policy are added in Android 11. system_ext policy and product policy are divided into public policy and private policy, like the platform sepolicy.

Additional Treble Features

• Android Q introduced the Android Pony EXpress (APEX) container format, which is used in the installation process for lower-level system modules.
• A native daemon called apexd oversees installing, verifying, and removing APEX files. This process starts early in the boot process and is prepared.
• The device often comes with APEX files pre-installed under /system/apex. If no updates are available, the APEX manager returns to using these packages.
• Android 10 introduced the Dynamic System Updates (DSU) system feature, which performs the following functions:
  • Creates a fresh Android system image (GSI) for your device to download.
  • Creates a new dynamic partition.
  • GSI is loaded onto the new partition.
  • Enables the device to boot the GSI as a guest OS.

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.

HSC's Android Treble Implementations

• We have created custom devices and added product and board configs.
• Converted mk files to bp files.
• Involved actively in porting custom features from Android 10 to Android 12.
• To make Stable AIDL’s.
• Sepolicy restructuring by moving the product-specific rules.
• Added compatibility matrices and manifests.
• Replaced Qualcomm-based system image from GSI 10 to 12 with existing vendor implementation still in A10.
• Disabled Dynamic partitions (super image).
• Build script modifications.
• Working on generating the OTA for both incremental and version upgrade.