When we talk about the integration of a new type of hardware module inside Android, that means we will cover the following aspects: HAL implementation for Linux driver manipulation, JNI implementation for HAL Java wrapper, Service Provider implementation for Android Framework invocation, and the functional test application code.
What I will depict are based on Jollen’s mokoid codebase.
HAL Implementation
The reasons of the existence of HAL:
1. Not all hardware devices can provide standard Linux device driver interface;
2. The standard Linux device driver must be comply with GPL that maybe conflict to some hardware vendors’proprietary;
3. Android has some specific control on some particular hardware module.
HAL resident directories in Android codebase
Generally, HAL resides in the following subdirectories:
libhardware_legacy/ -- Legacy architecture for hardware integration
libhardware/ -- HAL stub
ril/ -- Radio Interface Layer
mx5x/ -- Freescale i.MX5x associates including Gps、Vibrator、Wifi、Copybit、Audio、Camera、Lights、Ril、Overlay etc.
First, I will focus on the legacy arch of HAL implementation because that would be more familiar to guys who have experiences on JNI invocation and implementation.
Hightlights on HAL implementation:
1. Being as a kernel driver's agent, i.e. associate with the open device node, issue IOCTL commands etc.
2. Utilize structure hw_module_t, structure hw_module_method_t, and structure hw_device_t (standard structures defined in Android) to encapsulate itself to be recognized by Android JNI layer.
Reference Relations among These 3 Structural Typed Instances
