Think of the HAL as a published API for functionality to be provided by shared libraries that are to be provided by ODMs. That API is what's used by Android's core services to talk to the hardware. Those services know nothing of the hardware other than that API. So long as the requisite shared libraries (i.e. ".so" files) are available, "Android" (i.e. the system's core services) will be able to interface with the hardware.
There are two general categories of HAL components, those explicitly loaded (through a runtime dlopen()) and those automatically loaded by the dynamic linker (libhardware_legacy.so). The API for the former are in <aosp>/hardware/libhardware/include/hardware and the API for the latter are in <aosp>/hardware/libhardware_legacy/include/hardware_legacy. The trends seems to have been moving away from "legacy".
The interface between those ".so" files and the actual drivers through /dev entries or otherwise is up to the ODM to specify. Android doesn't care about that. It only cares about the HAL .so modules.
Hope this helps, -- Karim Yaghmour CEO - Opersys inc. / www.opersys.com http://twitter.com/karimyaghmour On 12-07-06 05:34 AM, ravikumar b wrote:
HI all, can please explain how Android Hal layer work with linux kernel., and how its communicate from low level to high level. -- unsubscribe: android-porting+unsubscr...@googlegroups.com website: http://groups.google.com/group/android-porting
-- unsubscribe: android-porting+unsubscr...@googlegroups.com website: http://groups.google.com/group/android-porting