Android O HALs switch to using binder

[satur9nine]

This page https://source.android.com/devices/architecture/hidl/binder-ipc describes a change to how HALs work in Android O:

"Starting in Android O, the Android framework and HALs now communicate with each other using binder"

Previously it seems most Android services would search for the vendor implementation of HAL functionality in shared library (.so file) and then use dlopen to load it and run the functionality in the same process. Now there are processes for all the HALs. Does anyone have any insight into the advantage of this change? It seems that if vendor HAL code crashes then the system process would crash in pre-O versions but in O it might be able to continue executing if it handles the remote error properly. Of course even if it keeps executing during a HAL process crash the device might not perform what the user wanted anyway. Is there some other advantage? Disadvantages to having a bunch more processes running and communicating over IPC seem obvious: increased memory usage and decreased performance.

Jacob

[satur9nine]

Answering my own question here, I see the main reason for the switch to having vendor HAL implementations running in their own process is basically an attempt to solve the dependency hell problem.

A system image update may contain an upgrade a dynamic native library (.so file) to a newer version with fixes and behavior changes, but if a vendor library in the vendor image requires the old version it is impossible for the system code and vendor code to run in the same process like they did before. By isolating vendor code to its own process the vendor code can continue to use the older dynamic native library while system code uses a newer version of the library. Some libraries in the system image are guaranteed to have stable APIs so that they won't have to duplicate every library. See VNDK at https://source.android.com/devices/architecture/vndk/ for more information. 

Jacob