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 the Treble Project 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 came out, 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).

The introduction of a new vendor interface between the Android OS framework and the vendor implementation achieves this. A Vendor Test Suite (VTS), analogous to the CTS validates the new vendor interface, to ensure its forward compatibility. Versioning is 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 droid 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 device manifest describes the static component of what the device may offer the framework.
The framework compatibility matrix describes what the Android framework anticipates from a specific device. The composition of the matrix is manually decided during the creation of the upcoming Android framework version, making it a static entity.

The manifest describes the high-level services that the framework can offer the device.
The device compatibility matrix describes the services that the vendor image expects from the framework.

To guarantee that a device receives framework updates compatible with its capabilities, the system must reconcile these two pairs of manifests and matrices at OTA time. A compatibility matrix generally outlines the requirements, while a manifest outlines what is offered.

The HAL interface definition language describes the vendor-framework interface.

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 is ready for immediate use. Earlier, it was 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 Project 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.