what is advantage of binderised hidl comparing to passthrough?

Question

In android, what's advantage of binderised hidl comparing to passthrough hidl?

As i know, there are two hidl way (binderised way(client/server in seperated process) , passthrough way (client /server in same process). What is advantage of binderised way comparing to passthrough way?

I think binderised way has more overhead than passthrough because binderised way need to use binder communication(RPC).

Why does vendor use binderised way?

Answer 1

binderized means that your service is provided via /dev/hwbinder and hosted in a separate process. This allows it to have exclusive access to a hardware resource and still offer the service to multiple clients at once.

passthrough means that your service is provided via a C++ interface in a shared library. This usually implies that only one client can link to it or the service must be implemented in a way that it does not need exclusive access to hardware. The upside is that you save the communication overhead of using Binder.

You would typically use binderized HALs as the the Binder RPC overhead is really small (smaller than with framework Binder and AIDL).

There is a list of HALs that need to be implemented in passthrough mode (for performance reasons), and a list of HALs that need to be implemented in binderized mode.

Answer 2

There's actually more to it than the above answer, which is somewhat inaccurate. "Binderized" indeed means that the service is hosted by a server, accessible over hwbinder, but it has little to do with exclusivity (which passthrough hals do NOT imply, and in fact multiple clients can link with them - the exclusivity is solely at the discretion of the kernel driver).

As part of Project Treble (Android 8.0 refactoring and moving into /vendor, /product, /odm), Google brought in the notion of a Binderized HAL to make sure no vendor HAL code intermixes with AOSP code. Numerous times before this, vulnerable vendor code executed in the context of system_server, and he owns system_server owns Android (i.e. complete and utter system compromise).

Using binderized HALs incurs the same nasty overhead (actually about the same as framework binder and AIDL), but allows complete separation of vendor code. Vendor code can no longer access AOSP services - that is, vendor daemons can open /dev/vndbinder , but not /dev/binder - which means that even if they are compromised there is more chance of containment, preventing malicious code from attacking AOSP services.

Passthrough HALs are definitely better and far more performant - but explicitly deprecated by Google (with the exception of android.hardware.graphics.mapper and maybe one or two more which elude me at the moment). They were allowed in 8.0 as part of the transition period , so as not to "shock" vendors too much. At this point (11.0, 12b3), they are not allowed on Android (per CTS, though vendors can still flout this)