Project Treble: Architectural Decoupling
Project Treble, introduced in Android 8.0, fundamentally restructured the Android OS framework. Its primary goal was to separate the device-specific, lower-level software written by silicon manufacturers and OEMs from the core Android OS framework maintained by Google.
Prior to Treble, updating the Android OS required silicon vendors to update their custom code for every new OS release. With Treble, a stable Vendor Interface (VINTF) acts as a strict boundary. As long as the device vendor's implementations conform to this interface, the Android framework can be updated independently.
The Hardware Abstraction Layer (HAL)
The HAL is the cornerstone of this separation. It defines a standard interface that hardware vendors must implement to expose their device's capabilities to the higher-level Java framework.
With Treble, HALs were formalised into independent processes. The Android framework communicates with these HAL processes using Inter-Process Communication (IPC) via Binder. This architecture is known as "Binderized HALs".
AIDL vs HIDL: The Interface Definition Languages
To facilitate communication across the VINTF boundary, interfaces must be rigorously defined.
HIDL (HAL Interface Definition Language)
Introduced with Treble, HIDL was created specifically to define HAL interfaces. It allowed for strongly typed interfaces and data structures. HIDL interfaces are versioned (e.g., android.hardware.camera.provider@2.4), ensuring backward compatibility.
AIDL (Android Interface Definition Language)
AIDL has existed since the early days of Android, primarily for application-level Binder IPC. In recent Android versions, Google has strongly pushed for unifying all IPC under AIDL, deprecating HIDL for new HAL development.
The Decision Tree:
- Legacy HALs: Many existing HALs are still written in HIDL.
- New HALs (Android 11+): All new HALs should be written using Stable AIDL. Stable AIDL provides better tooling, closer integration with the core Binder system, and guarantees ABI stability.
VINTF Compliance Checking
The Vendor Interface Object (VINTF) mechanism ensures that the framework and vendor components are compatible before the device fully boots.
VINTF relies on two manifests:
- Framework Manifest (
/system/etc/vintf/manifest.xml): Declares the HAL versions the framework requires. - Device Manifest (
/vendor/etc/vintf/manifest.xml): Declares the HALs and versions the vendor provides.
During boot, the vintf service verifies that the device manifest satisfies the framework's requirements. If a required HAL is missing or the versions are incompatible, the device will fail to boot, preventing unstable configurations.
You can inspect VINTF information using adb:
adb shell vintf
VNDK (Vendor NDK) Compliance
The Vendor NDK is a specific set of libraries provided by the system that vendor HALs are permitted to link against. It ensures that vendor code does not rely on private, unstable system libraries.
VNDK enforces ABI stability. If a vendor binary links against a VNDK library (e.g., libutils.so), it is guaranteed that this library will remain available and binary-compatible across system updates.
VNDK Namespaces
To prevent vendor modules from accidentally loading system libraries (and vice versa), the dynamic linker (linker64) uses namespaces. Vendor processes are restricted to loading libraries from their own partition (/vendor/lib64) and the explicitly defined VNDK libraries from the system partition.
To check library dependencies and VNDK compliance, use tools like readelf or ldd on device binaries:
# Check shared library dependencies of a vendor binary
adb shell readelf -d /vendor/bin/hw/android.hardware.camera.provider@2.4-service