hal代碼分析遇到问题及解决.docxVIP

7月19日-----20日 学习工作记录 1．资料 下了Android技术内幕那本书，貌似不错，除了硬件抽象层那一张，其它的也要抽空看一下。 不错的HAL层分析的网址 HYPERLINK /hongtao_liu/article/details/6060734 /hongtao_liu/article/details/6060734 2.Apache License 2.0 　　Apache License是著名的非盈利开源组织Apache采用的协议。该协议和BSD类似，同样鼓励代码共享和尊重原作者的著作权，同样允许代码修改，再发布(作为开源或商业软件)。需要满足的条件： 　　1． 需要给代码的用户一份Apache License 　　2． 如果你修改了代码，需要在被修改的文件中说明。 　　3． 在延伸的代码中（修改和有源代码衍生的代码中）需要带有原来代码中的协议，商标，专利声明和其他原来作者规定需要包含的说明。 　　4． 如果再发布的产品中包含一个Notice文件，则在Notice文件中需要带有Apache License。你可以在Notice中增加自己的许可，但不可以表现为对Apache License构成更改。 Apache License也是对商业应用友好的许可。使用者也可以在需要的时候修改代码来满足需要并作为开源或商业产品发布/销售。 3．HAL简介 3.1Android HAL存在的原因 主要有： 1. 并不是所有的硬件设备都有标准的linux kernel的接口 2. KERNEL DRIVER涉及到GPL的版权。某些设备制造商并不原因公开硬件驱动，所以才去用HAL方式绕过GPL。 3. 针对某些硬件，An有一些特殊的需求 3.2现有HAL架构 由Patrick Brady (Google) 在2008 Google I/O演讲中提出的 两种HAL架构比较 目前存在两种HAL架构，位于libhardware_legacy目录下的“旧HAL架构”和位于libhardware目录下的“新HAL架构”。两种框架如下图所示。 libhardware_legacy 是将 *.so 文件当作shared library来使用，在runtime（JNI 部份）以 direct function call 使用 HAL module。通过直接函数调用的方式，来操作驱动程序。当然，应用程序也可以不需要通过 JNI 的方式进行，直接加载 *.so （dlopen）的做法调用*.so 里的符号（symbol）也是一种方式。总而言之是没有经过封装，上层可以直接操作硬件。 现在的libhardware 架构，就有stub的味道了。HAL stub 是一种代理人（proxy）的概念，stub 虽然仍是以 *.so檔的形式存在，但HAL已经将 *.so 档隐藏起来了。Stub 向 HAL提供操作函数（operations），而 runtime 则是向 HAL 取得特定模块（stub）的 operations，再 callback 这些操作函数。这种以 indirect function call 的架构，让HAL stub 变成是一种包含关系，即 HAL 里包含了许许多多的 stub（代理人）。Runtime 只要说明类型，即 module ID，就可以取得操作函数。对于目前的HAL，可以认为Android定义了HAL层结构框架，通过几个接口访问硬件从而统一了调用方式。 Android的HAL的实现需要通过JNI(Java Native Interface)，JNI简单来说就是java程序可以调用C/C++写的动态链接库，这样的话，HAL可以使用C/C++语言编写，效率更高。 3.3．HAL的实现 HAL实际就是一个硬件抽象层的框架，其硬件设备的具体操作由对应的stub进行简介回调。 HAL位于以下两个文件中。 Hardware.c (libhardware) Hardware.h (libhardware\include\hardware) Hardwaer.h中定义了三个重要的结构体 struct hw_device_t struct hw_module_t struct hw_module_methods 其中hw_device_t表示硬件设备，存储了各种硬件设备的公共属性和方法。如果要移植或者添加新设备，那么都需要使用该结构体进行注册，其中的tag必须初始化。 代码如下： 结构体hw_module_t在进行加载的时候用于判断属于哪一个module。 代码如下： 结构体hw_module_methods_t用