Android HAL架构

现有HAL架构由Patrick Brady (Google) 在2008 Google  I/O演讲中提出的。
Android HAL模块实现- https://my.oschina.net/haomcu/blog/473919
> HAL是为了隔离Android Framework和Linux内核；内核空间和用户空间。
libhardware_legacy/ - 旧的架构、采取链接库模块的模式进行。
libhardware/ - 新架构、调整为 HAL stub 的概念。

Android的HAL（Hardware Abstract Layer硬件抽象层）是为了保护一些硬件提供商的知识产权而提出的，是为了避开linux的GPL束缚。思路是把控制硬件的动作都放到了Android HAL中，而linux driver仅仅完成一些简单的数据交互作用，甚至把硬件寄存器空间直接映射到user space。而Android是基于Aparch的license，因此硬件厂商可以只提供二进制代码，所以说Android只是一个开放的平台，并不是一个开源的平台。

> HAL(hardware abstract layer)是位于操作系统与硬件之间的接口层，目的在于硬件抽象化。它存在于linux的应用层，它在Android系统中的位置是：向下连接驱动，向上给JNI提供接口。
1. libhardware_legacy（*.so）为过去的HAL目录，采用链接库模块概念的旧架构，audio,power,wifi,vibrator,uevent等有使用该架构。
  HAL架构继承的是老的linux共享库思路，把硬件接口都打包到libhardware_legacy.so，Android的JNI在要调用到这个库的硬件接口函数时，只要将Android.mk中的LOCAL_SHARED_LIBRARIES增加libhardware_legacy就行，这样就会到共享库中获取接口。缺点：多个进程使用时，会映射到多个进程空间，造成浪费。

2. libhardware(HAL Stub)为当前使用的HAL架构，audio,bluetooth,camera,fb,gps,lights,power,sensor,rtc,nfc等有使用该架构。
  HAL架构是当前Android源码中使用的思路，每一个硬件模块称为一个stub（代理人），并且借尸so的形式编译，所有的stub都要通过libhardware.so(由hardware.c)才能找到每一个stub，才能回调每一个stub中硬件抽象接口，当然stub在编写时需要按照HAL_MODULE_INFO_SYM的格式来写，通过libhardware.so找到stub时，就会将该stub加载到内存，返回该stub的模块指针。优点：采用HAL module和HAL stub结合形式，HAL stub不是共享库，上层只拥有访问stub的函数指针，并不需要stub，Runtime只需要根据module ID并通过HAL module提供的统一接口就能取得stub的操作函数，只会被映射到一个进程，不会浪费空间。