Stray Insights

Introduction. We saw in the earlier tutorial an overview of the changes done as part of Project Treble. We also understood how decoupling the Vendor HAL implementation from the core system framework avoids re-working on the HAL. In this tutorial let us start looking at the core differences in detail. During the analysis we will also learn the core components and the major how to do’s for being Treble compliant. Binder Changes. For Treble to work and decouple the HAL’s from the core framework, A lot of changes were done to the existing binder infrastructure. Some of these are. 1.      support multiple /dev instances. 2.      Support multiple selinux contexts for these owners of the binders dev. The binder.devices parameter is a comma-separated list of strings that specifies the names of the binder device nodes that will be created. Each binder device has its own context manager, and is therefore logically separated from the other devices.

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