Karim Yaghmour, CEO Opersys inc. (www.opersys.com)
Inside Treble (continued)
This is a continuation of the “Inside Treble” section of Part III.
Vendor NDK (VNDK)
As I mentioned earlier, the lack of testing of the native layer by the CTS made it such that “anything goes” underneath the framework. Since there was no limit to what could be done under the hood, some vendors could take this to extremes. Imagine for a second that you’re a handset manufacturer. You’re working on your new flagship product and you know that when it comes out the trade-press will be all over it, evaluating it under every possible angle, including running several benchmarks and then publishing it all for consumers to use as guidance for purchasing (or not) your new device. Given that you have in-house experts that know your hardware’s intricacies, you have every benefit of going through every possible library and component in the system and tweaking or extending it in as much as possible so that its performance is blazing fast on your hardware while still preserving battery life. You might even want to detect when a certain benchmark tool is running to tweak your processors’ behavior accordingly.
In short, there could be significant differences between the native layer libraries and components shipped by Google for a given version of Android and the libraries and components found in an actual device in the market running that very same version. Insofar as upgradability is not an objective, that’s not an issue. But given that Treble’s purpose is specifically to enable easier, faster and less costly upgrades, Google needed to put some order in this mess.
The purpose of the Vendor NDK (VNDK) is to provide pre-defined ways by which to mitigate and formally manage the differences that can occur between the Google-minted native libraries and those provided or modified by vendors. Without such clean definitions, it would not be possible to update the framework without risking a mismatch with vendor-customized libraries. Given the large number of libraries involved and the many different ways in which libraries can be used, the VNDK documentation introduces quite a few concepts and categories to abide by when working with libraries and when implementing modules that depend on libraries.
It’s beyond the scope of this post to detail the VNDK further. However, you’ll likely want to spend some time gathering a solid understanding of its intricacies and their ramifications with regards to your system. The abstractions introduced by the VNDK are more subtle than those introduced by HIDL, but they are no less critical.
This is one aspect where Google is effectively recognizing that the open nature of Android enables downstream parties to practically do anything they want. The VNDK is a careful exercise aimed at preserving this freedom to tinker while still making it possible to update the system in a coherent fashion.
Vendor Interface Object (VINTF)
When new versions of Android do get released, there will be a need for the OTA process to validate whether your existing vendor interface implementation can support the new release. Specifically, it’ll need to verify whether the following match or are compatible:
– HIDL versions
– Kernel specifics
– SE policies
– Android Verified Boot (AVB) version
To that end, Treble defines the Vendor Interface Object (VINTF) which is a way to describe a device for OTA purposes. The following diagram illustrates how VINTF is used:
Upon a device OTA, the device manifest is used by to check if the hardware support it implements is still supported by that framework. Conversely, the framework manifest is used to enable the vendor image to check if the framework provides the services it needs. At OTA time, the device manifest is provided by the device whereas the framework manifest is provided by Google. The framework compatibility matrix describes what the framework expects of the device hardware and the device compatibility matrix describes what the device expects of the framework. At OTA time, The framework manifest is tested against the device compatibility matrix and the device manifest is tested against the framework compatibility matrix. Google’s online documentation explains the manifest format, the compatibility matrices format and explains the matching rules between the two.
If you want to be able to do OTAs on your device, this is one aspect you’ll likely want to spend some time investigating.
Vendor Test Suite (VTS)
The Vendor Test Suite (VTS) is similar in nature to the CTS except that it validates the functionality of the layers underneath the framework instead of the app development API. Specifically, the VTS includes the following top-level categories of tests:
– HIDL HAL Tests
– Kernel Tests
– LTP
– Linux Kselftest
– VNDK (Vendor Native Development Kit) Tests
– Performance Tests
– Fuzz Tests
– Security Tests
The official VTS documentation provides an operator’s view of the VTS, including coverage of the web-based VTS dashboard for continuous integration (CI). The Android sources include some more in-depth information about VTS and the location of the specific tests it conducts.
Remember, this is the way by which Google ensures everything it did with Treble accomplishes its ultimate goal of making updates easier, faster and less costly. Even if you don’t aim at getting any sort of certification from Google, running VTS will allow you to get a good understanding of whether you’ll be able to benefit from the infrastructure Treble gives.
Implications for custom devices
Treble has a number of ramifications for custom device developers. First and foremost, if you are interested in GMS certification in any way then the surface of modifications you can do has shrunk quite significantly. Here’s a non-exhaustive list of internal modifications which have essentially become no-go with Treble for those seeking certification:
– System service internals
– HAL definition reworking/extension
– Core library replacement by tweaking dependent components’ APIs
– Tweaking existing SE policies
– Any change that impacts OTA
– Any change that breaks VTS
One could argue that such modifications shouldn’t have been done in the first place. Still, even for those changes that are permitted by Treble, the engineering effort overhead has increased significantly. Whereas in the past, for instance, tweaking a native library was just a matter of opening the relevant files and making modifications to them, the VNDK now imposes a whole new set of rules to do that properly. Whereas in the past, for example, it was possible to extend the functionality of some system services by modifying them and possibly tweaking the corresponding HAL definitions, one is now forced to create a vendor-specific system service and possibly a custom HIDL interface for a custom hardware type.
If you don’t want to get certification, you’ll have to admit that being able to continue upgrading your devices to the latest version of Android with little to no effort would be great. Hence, if you want to benefit from the edifice Google is building with Treble you’ll still likely want to continue working on the stack as if you were seeking certification and therefore you’ll need to obey the rules set by Treble. You can always forgo this, and continue customizing Android’s guts in whichever way you see fit. But chances are that device you create will then be like most other custom Android devices released before it: it won’t ever get any OS updates.
Treble also implies that the work done by SoC vendors is going to have to be conducted in a more structured fashion. This should certainly be a benefit to anyone working on custom devices, whether they desire certification or not. Most SoC vendors will likely have an incentive to deliver BSPs that can be used to create Android releases that pass VTS, just because they’ll surely have a significant subset of customers that require it. As we saw, however, this work will not necessarily be trivial, in the beginning at least. I would therefore expect that some SoC vendors may struggle in their initial efforts to getting BSPs that are fully Treble compliant. You’ll likely want to add “VTS BSP validation” as one of your criteria for selecting SoC vendors for your next project. By the same token if you outsource your device’s development then you’ll want to mention very early on whether passing VTS is a requirement for you as well as making sure the party you are working with fully understands the implications.
Closing Recommendations
It will take several years before the benefits of Treble are realized. Google has however established some very solid ground work. I, for one, very much look forward to not having to dread whether the Android device I have in my hands will get updated to future Android releases or not. Still, there is quite some work to get to that. For one thing, I fully expect that Google and the Android ecosystem around it will learn their way through this organically and will have to make adjustments along the way. It’ll probably take a few iterations to iron out the kinks from the entire process.
In the mean time, here are some recommendations, in no specific order:
- Make sure you have a firm understanding of how Treble changes your Android device design, development, integration and support plans.
- Have your technical teams review the Treble documentation made available by Google and possibly seek training so they can start familiarizing themselves with its intricacies.
- If certification is on your agenda, start paying special attention to the VTS in your planning. If you have CTS as part of your checklists, a good start is adding equivalent entries for VTS.
- When selecting partners or suppliers, make sure their work and/or the software they deliver falls in line with Treble’s requirements, especially if certification is a target.
Live Sessions
I will be hosting two separate YouTube live sessions on March 27th and 28th, one on Treble and one more specifically on HIDL:
Acknowledgements
Several diagrams used here are distributed by Google under CC-BY-SA license.
About The Author:
Karim Yaghmour is part serial entrepreneur, part unrepentant geek. He’s most widely know for his O’Reilly books: “Building Embedded Linux Systems” and “Embedded Android”. As an active member of the open source community since the mid-90’s, he pioneered the world of Linux tracing with the Linux Trace Toolkit.
© 2018, Opersys inc., /
