Android硬件抽象层HAL之深入剖析.docVIP

作为一个搞android驱动或者说搞底层的人，我觉得对于hal那是必须要掌握的，而且必须达到一定深度，于是我总结了一下，将整个自己的分析思路写下来。 主要是看android源代码，根据源代码得到的思路。(看源代码比看什么著作书籍都管用) android HAL是什么？为什么有它？ 硬件抽象层是介于android内核kernel和上层之间的抽象出来的一层结构。他是对linux驱动的一个封装，对上层提供统一接口，上层应用不必知道下层硬件具体怎么实现工作的，它屏蔽了底层的实现细节。 它在整个android架构中的位置如下图所示： 传统的linux对硬件的操作基本上在内核空间的linux驱动程序中实现了，那么现在为什么那么多此一举把对硬件的操作分为两部分，hal和linux驱动呢？ 而且hal属于用户空间，linux驱动属于内核空间。其实并不多余。那么为什么要高出这么个东西，理由是很多的： 1.谷歌搭好了hal的框架，为上层framework打通过jni调用hal提供了统一的api，硬件开发商或者移植人员只需要按照框架开发即可，无需话费精力在与上层的交互上的实现上，将精力放在hal层本身的实现上即可。 2.从商业角度，许多硬件厂商不愿意将自己硬件相关一些核心的东西开源出去，假如将对自己硬件的驱动程序全部放入内核空间驱动程序实现，那么必须遵循GPL协议，是必需开源的。有了HAL层之后，他们可以把一些核心的算法之类的东西的实现放在HAL层，而hal层位于用户空间，不属于linux内核，和android源码一样遵循的是appache协议，这个是可以开源或者不开的。 ? 搞清楚了hal的存在意义，下面来根据hal层源码分析一下hal到底是怎么样个架构和实现原理，深入剖析一下。 android hal层的代码主要位于/hardware/libhardware下面我们从上往下走。 在hal层中，各类硬件的都是以硬件模块的形式描述的hal层中是用hw_module_t结构体来描述的，而每一类硬件模块中又有各个独立的硬件，hal中是用hw_device_t结构体来描述的。 上层app通过jni调用硬件时，首先得获取到hw_module_t结构体，也即是硬件模块，有了这个才能再对硬件进行操作。那么我们来看看看看这两个结构体定义是什么样子的。 它们的定义在/hardware/libhardware/include/hardware/hardware.h里面。 a.? hw_module_t表示硬件模块，它主要包含了一些硬件模块的信息，结构体的定义： /** * Every hardware module must have a data structure named HAL_MODULE_INFO_SYM * and the fields of this data structure must begin with hw_module_t * followed by module specific information. */ typedef struct hw_module_t { /** tag must be initialized to HARDWARE_MODULE_TAG */ uint32_t tag; ?//tag，根据引文注释可以看到必须被初始化为HARDWARE_MODULE_TAG /** major version number for the module */ uint16_t version_major;//主版本号 /** minor version number of the module */ uint16_t version_minor;//次版本号 /** Identifier of module */ const char *id;//模块id字符串 /** Name of this module */ const char *name;//模块名 /** Author/owner/implementor of the module */ const char *author;//作者 /** Modules methods */ struct hw_module_methods_t* methods;//硬件模块方法结构体 /** modules dso */ void* dso;//打开硬件模块的库时得到的句柄 /** padding to 128 bytes, reserved for future use */ uint32_t reser