[Treble-Enabled Device Development A/AB ROMS] phhusson:
Project Treble provides a great help in getting access to vendor-specific HALs, I'll try to explain how, and how to exploit it.

Presentation of vendor HIDLs

Thanks to Project Treble, all HALs must be defined through HIDL.

Standard AOSP HALs means that a generic AOSP system works with standard AOSP features.

But, vendor HALs are also going through HIDL!

APIs defined through HIDL are stable, versioned, hashed and easy to access.

Just plug the HIDL inside your build system, and you get easy access from your applications to the HAL behind the HIDL!

Also, APIs defined through HIDL are supposed to be clean, and mostly self-documented, so getting the HIDL can help understand how the HAL works.

To understand how easy it is, here is a real world client usage of an HIDL:

IExtBiometricsFingerprint service = IExtBiometricsFingerprint.getService();
service.sendCmdToHal(NAV_ON);

With the HIDL, enabling gestures on the fingerprint sensor on Huawei devices is a two liners! [1]

Browsing vendor HIDLs

Now, the problem is that HIDLs are part of the source code, not the firmware.

So if the vendor doesn't publish it, there is some additional work to do.

Android build system is capable of generating two client APIs for HALs using HIDL. Either a C++ library, or a java library. Not all firmwares will contain java libraries for all APIs, but C++ is almost always available.

Both languages make it fairly easy to reverse engineer the prototype of the functions, which is almost all of HIDL (c++ is missing function arguments)

So, I made a script to reverse engineer those HALs ( https://github.com/phhusson/treble_experimentations/blob/master/vendor-HAL/reverse-hal.sh ).

It is far from perfect, it can't generate a full-blown HIDL, but it makes discovery much easier!

Here are a few examples of APIs it is giving access to:

- Touch screen gives us access to Glove mode and cover mode

- Display gives us access to functions like setColorTemperature, or updateRgbGamma

- Infrared HAL gives us access to learning capability

- fingerprint sensor gives us access to sendCmdToHal

With the first three examples, we can see things can be easy, but the last one makes things trickier. With the last one, there is still a magic value to give to the sendCmdToHal function.

Anyway, that's still quite an improvement compared to before Treble.

Using vendor HALs

So, let's say we've discovered vendor.huawei.hardware.tp@1.0::hwTsSetGloveMode(bool) function, and we want to call it.

As I mentioned in the first section, if we have the HIDL, it's a two liners.

But, we don't have it, so what do we do?

Android build system usually generates HIDL client code for C++ and Java, so we just need to piggy-back to this code to be able to call the functions!

Using vendor HALs from Java

For Java, the idea is fairly simple, we need to copy/paste the code from the original firmware (either from an app or framework), and copy it in our own environment.

It's a bit more complicated to realize, here is how I did it:

- grep -rF <name of the function> system # To find where to find the java symbols

This gave me system/system/framework/oat/arm64/hwServices.vdex

- deodex it

- Retrieve all symbols inside proper folder. In this case, vendor/huawei/hardware/tp

- Create a mock of the java class ( here is an example )

- Create the code to call this (here is an example)

- Build the mock and the caller (here is an example)

- Decompile the result into smali

- Replace the mock code by the actual classes from the original firmware

- Recompile the whole

- Run the resulting app/dex

Things to improve

First problem here, is this code is annoying to automate and put into a build system.

Them, we can only partially reverse-engineer the HIDL, which leads to two problems:

- We need to piggy-back previous firmware's APIs

- Calling C++ is much harder (because ABI behaviour when changing headers is tricky)

The cleanest solution would be to fully reverse-engineer the HIDLs.

Though current reverse engineering is so bad that it doesn't even list all the functions available, so a lot of work is needed.

Conclusion

Project Treble's HALs are fun to play with, look at it!

[1] I'm a bit lying here. This is enough to enable event reporting, but there are some additional changes needed to make sense of those events