第九章心得

这一章介绍HAL，全称为Hardware Abstract Layer，即硬件抽象层，它是建立在Linux驱动之上的一套程序库，程序库并不属于Linux内核，而是属于Linux内核层之上的应用层。为Android增加HAL的目的除了尽量避免应用程序直接访问Linux驱动外，还会保护私人财产。

在Android中加入HAL的原因如下：
在传统的Linux系统中Linux驱动一般有两种类型的代码：访问硬件寄存器的代码和业务逻辑代码。对于访问硬件寄存器的代码，都是调用Linux内核的标准函数进行标准操作。而Linux驱动的业务逻辑部分开发人员并不想将源代码公开，这些Linux驱动的实现涉及一些技术专利和商业机密，公开会有麻烦。但作为Linux驱动，又不得不公开源代码，因为Linux内核采用了GPL协议，而此协议要求所有使用基于GPL协议的源代码的程序必须开源。为了满足不想开源的要求，Google在Android层次结构中的系统运行库层增加了一个HAL，HAL并不是Linux内核的一部分，它位于Android的系统运行库层，Android采用Apache license2.0协议，该协议并未要求基于此协议的源代码的软件也必须开源，HAL属于Android的一部分，不必开源。对于不想开源的Linux驱动作者，Linux驱动只相当于一个“数据二传”，在Linux驱动中只保留与寄存器交互的代码，访问寄存器只有Linux内核的相关函数能做到，不想公开的业务逻辑代码放在HAL中。这样的话，Linux驱动就只剩下一个空壳，唯一的功能就是接收由HAL传来的数据，并将这些数据写入指定的寄存器中，或从寄存器中读取数据，并返回给HAL。带HAL的Linux驱动相当于将数据从HAL传到寄存器，或从寄存器传到HAL的“数据二传”。对于拥有完整功能的Linux驱动，也可加入HAL，不过HAL就成一个空壳了，它只负责与Linux设备驱动进行交互。

Google为Android加入HAL主要目的有：①统一硬件的调用接口。由于HAL有标准的调用接口，可利用HAL屏蔽Linux驱动复杂、不统一的接口②解决了GPL版权问题。由于Linux内核基于GPL协议，而Android基于Apache license2.0协议，Google将原本位于Linux驱动中的敏感代码上移了一个层次，这些代码摆脱了GPL协议的束缚，不想开源的Linux驱动就没必要开源了③针对一些特殊的要求。对于有些硬件，可能需要访问一些用户空间的资源，或在内核空间不方便完成的工作及特殊要求，这种情况下，可利用位于用户空间的HAL代码来辅助Linux驱动完成一些工作。

起初简单的HAL架构基本原理是在Android系统中使用程序库.so文件调用位于内核空间的一半通过设备文件访问的Linux驱动。然后Android应用程序apk文件可通过NDK程序访问HAL中的程序库，或直接在Android应用程序中访问HAL中的程序库，可直接使用Java代码访问。HAL架构中，HAL模块中的核心代码没有改变，只是增加了一些新的HAL架构要求的入口代码，使这些程序库可自动被Android系统识别。而调用HAL模块的代码并不需要直接装载.so文件，只需要通过一个ID定位相应的.so文件-Stub。在Stub和JNI间还有一层service程序库，该层的库文件使用Android系统提供的调用HAL的机制访问HAL中的service程序库，在这层通过ID定位了HAL library，然后Android应用程序再调用service程序库。Android HAL的源代码存储位置并不固定，一般会存储在<Android源代码>/hardware目录中。最终生成的.so文件主要放在Android系统的/system/lib/hw目录。