Yaghmour: Extending Android's HAL

True, Google does its best to keep its lead devices open source in as much as possible.

True, HAL modules aren't required to be binary only (and I don't think I said that.)

True, where possible, HAL modules use standard kernel functionality when possible.

However, to the exception of input/events (frameworks/base/services/input/EventHub.cpp opens /dev/input/* directly), my reading of the sources is that almost everything else goes through a HAL definition in either hardware/libhardware/include/hardware/*.h or hardware_legacy/libhardware/include/hardware_legacy/*h; there's of course storage that goes through vold and some of the networking going through netd. That is true even for HAL components (modules or parts of libhardware_legacy.so) that use standard kernel functionality (like power and wifi). IOW, in as far as I can see, the HAL isn't just for parts "where there isn't a clear, simple, and uniform kernel interface for something".

That said, my blog post was mainly technical and did not make a judgement call on any of the abstractions being used. However, as I said in one of the comments above, and this is a totally separate issue, the net result of Android's use of a HAL is that developers have far fewer open source examples to start from then when developers only had Linux kernel drivers to implement.

Simply because it turns out that, de facto, the HAL modules end up not being open sourced: the manufacturer isn't required to make them available, whether said HAL modules use std Linux interfaces or not. Manufacturer doesn't have to, so he doesn't. Software freedom and other moral issues asside, the reality is that this means that the vast majority of Android devices out there (most of which are not the lead device developed by Google) will never have their HAL modules implementations published. And that means there are few examples of HAL module implementations to look at for creating your own.