Android Treble Architecture: Part 2 - Overview of Changes for Treble

We already learnt in the previous tutorial how Treble is the prospective [Well, We would need to see how it really affects] solution to the problem of Fragmentation when it comes to getting smooth and quick updates of Android.

Is it Really required to be Treble compliant?

Well, There are 2 answers to this. YES & NO.

With Treble Google also introduces a set of tests aka VTS [Remember CTS for testing Android API compliance?] to test the vendor interfaces compatibility. This along with CTS is now the defacto requirement to get GMS certification. So, We can clearly see that if the device needs to be GMS compliant we would need to be Treble compliant. On the other hand if we were to decide that we donot need to be GMS compliant [I could think of some company making a product viz: a mediaplayer device capable of internet] without needing Google services we can still work around Treble.

In this tutorial, We will try and analyze the main differences between 2 Android versions before and after Treble to see what has changed. This will also enable us understand the main architectural changes which we might need to do to be Treble compliant.

Key Differences.

Before we begin let us revisit the Android component/system architecture. We can see that HALs [Hardware Abstraction Layers] are the gateway to accessing the hardware beneath any system. They are typically used by their service masters to get the hardware do the required task [like CameraService uses CameraHAL to start preview or take a picture].

Hardware Abstraction Layer (HAL)

A HAL defines a standard interface for hardware vendors to implement, which enables Android to be agnostic about lower-level driver implementations. Using a HAL allows you to implement functionality without affecting or modifying the higher level system. HAL implementations are packaged into modules and loaded by the Android system at the appropriate time.

In the previous Android system architecture, the Android Framework and the Android HAL’s [Hardware Abstraction Layers] were packaged into a system.img. The core android framework and the HALs were tightly coupled. The hardware related libraries were directly loaded into the process context using links or dlopen calls [Typically these HALs were in /system/lib/hw].

The general architectural framework between the framework and HAL in the old version of the android system framework could look more similar to the following figure.

As seen from the above figure, Since there is no clear demarcation between the process service and the HAL there are potentially 2 problems in here.

1.     Any crash or misbehavior in the HAL would easily cause the process to crash with it.

2.     Any update in the Framework layer would typically need a re-work in the HAL during an update.

With Treble, Android introduces a new way to load and use these HAL’s where it gets decoupled from the main process context and also does not need an update [Even a recompilation] separately to update the core Android Framework.

The following figure explains this more.

From the above figure we see, The vendor HAL is called using a new binder interface called hwbinder [This makes a process cross over and ensures that even if the HAL crashes the process does not].

Because of this decoupling now the vendor HAL is independent of the core framework [service], The framework can be updated with very little or no impact from the HAL.

Partitioning.

With this new way of loading and using the vendor HAL’s , Android also compartmentalizes the core framework code [system.img] and the Vendor HAL’s  [vendor.img].

Many of us would know that the concept of vendor.img already existed earlier, However, It gets enforced now to create this divide and decouple things.

The following picture explains this new partition architecture.

·       system.img. Contains mainly Android framework.

·       boot.img. (kernel/ramdisk) Contains Linux kernel + Android patches.

·       vendor.img. Contains SoC-specific code and configurations.

·       odm.img. Contains device-specific code and configurations.

·       oem.img. Contains OEM/carrier-related configurations and customizations.

·       bootloader. Brings up the kernel (vendor-proprietary).

·       radio. Modem (proprietary).

Prior to Android 8.0, the vendor, odm, and oem images were optional; files belonging to these images were placed in boot.img or system.img with symlinks (such as /vendor or /system/vendor) when absent.

Android 8.0 makes the vendor partition mandatory.

The goal is to modularize Android partitions and make them interchangeable by defining a core, standard interface between the Android Platform (on system.img) and vendor-provided code. This standard interface enables the Android Platform to be updated without affecting the SoC and ODM partitions.

For example, it should be possible to upgrade a device system.img from Android 8.0 to Android P while other images (such as vendor.img, odm.img, etc.) remain at Android 8.0.

This modularity enables timely Android platform upgrades (such as monthly security updates) without requiring SoC/ODM partners to update SoC- and device-specific code.

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

The new [read updated/upgraded] system.img will not affect Vendor HAL Implemetation.

The above figure explains in an oversimplified way, how this new structure help in decoupling and getting quick updates across an Android Device.

We have already in a nutshell seen how this Treble would help in getting updates faster. This new way of things also do give us an hint on what could have changed.

In the next set of tutorials, We will see these changes in greater detail starting with the kernel itself.