An Android 101: Hardware and HAL
Unlike traditional Linux based systems, Android applications communicate with the underlying hardware through Java APIs not by system calls.
Figure 1: Android vs a Tradition Linux system.
Most of the ‘shared libs’ in the above diagram represent the HAL modules. The Hardware Abstraction Layer or HAL is the glue between any device (part of the kernel) and the corresponding JNI interface.
The details about the HAL is usually not of interest to application developers. However it is an important module for hardware vendors and OEMs involved in porting android into their own hardware and adding new hardware.
The HAL source code reside under the hardware folder . OEMs maintain a top level root directory and internally there are several HAL modules for the corresponding hardware.
On device ,the HALs live as .so’s either in ‘/system/lib/hw’ or ‘/vendor/lib/hw’. The HAL modules follow a certain nomenclature as defined here . Android relies on this naming convention to load the right HAL module for a given hardware and board configuration.
The HALs get loaded by its clients using the hw_get_module. This method relies on the values set to ro.hardware , ro.product.board and some other ro properties to load the correct .so. The complete list is here.
For eg. The SurfaceFlinger is the system wide compositor and the hardware composer is a HAL that abstracts device specific composition logic. The SurfaceFlinger loads the hardware composer using the hw_get_module method to get a handle of the HAL.
Each HAL implements a set of hooks which get called by their invoking service. The contract between the system service and the HAL is well defined. Device makers should ensure these interfaces are implemented as expected by the Android services. The figure below tries to show some of the HALs on the Android ICS version and key methods that HAL writes should implement.
With the newer versions of Android ,the scope of HALs have expanded and it is likely they will be used not just to abstract hardware but to abstract any device specific behavior.
1. Good site about adding support for a Camera : http://processors.wiki.ti.com/index.php/TI-Android-DevKit-Camera_Porting_Guide
2. Patrick Brady’s Google I/O talk: https://sites.google.com/site/io/anatomy–physiology-of-an-android
3. Figure 1 courtesy: http://www.cmg.org/measureit/issues/mit78/m_78_3.pdf
4, Class diagrams created using Umbrello ,an open source UML Modeler.
Update: Here is a new post on the same topic with much more detail: http://www.opersys.com/blog/extending-android-hal