android_HAL框架源码分析

ANDROID HAL
Albert Luo

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;//硬件模块方法结构体
  /** module's dso / void dso;//打开硬件模块的库时得到的句柄
  /** padding to 128 bytes, reserved for future use */ uint32_t reserved[32-7];

} hw_module_t;

前面tag，name那几个成员属性就不说了，看了注释相信大家都知道了，下面看看hw_module_methods_t,这个指针methods它指向的是与本硬件模块相关的方法的结构体，里面不用看可以猜出肯定有一些函数指针，但是它里面只有一个函数指针。可以看看定义：

1 typedef struct hw_module_methods_t { 2 /** Open a specific device / 3 int (open)(const struct hw_module_t module, const char id,//打开硬件设备函数指针 4 struct hw_device_t** device); 5 6 } hw_module_methods_t;

我们可以看到确实只有一个函数指针，open它是打开硬件模块中硬件设备的函数。 然后是成员void* dso，它是打开硬件模块相关的额设备之后返回的句柄给它，这个在后面看hw_get_module函数源码的时候你就会明白。 b. 下面我们再来看看hw_device_t结构体,这个结构体主要是用来描述模块中硬件设备的属性信息什么的。一个硬件模块可能有多个硬件设备。 比如说，传感器模块，sensor_module,是一个硬件模块，但是手机中的传感器就对应的有好多种，比如加速度acc_sensor,磁传感器M_sensor等，那么他们都属于sensor_module,但是他们有都有自己的 hw_device_t结构体来描述。hw_device_t定义：

1 /** 2 * Every device data structure must begin with hw_device_t 3 * followed by module specific public methods and attributes. 4 / 5 typedef struct hw_device_t { 6 /* tag must be initialized to HARDWARE_DEVICE_TAG / 7 uint32_t tag; //设备tag 8 9 /* version number for hw_device_t / 10 uint32_t version;//版本 11 12 /* reference to the module this device belongs to / 13 struct hw_module_t module;//本设备归属的硬件模块 14 15 /** padding reserved for future use / 16 uint32_t reserved[12];//保留 17 18 /* Close this device */ 19 int (close)(struct hw_device_t device);//关闭设备的函数指针 20 21 } hw_device_t;

其中，第三个成员module指向的是这个设备归属的硬件模块结构体。 最后一个函数指针close指向的肯定是关闭设备的函数。

恩，到此，hal的主要的两个结构体讲完了，下次我们继续，将结合源码，看看hal层到底是怎么工作的，看看上层怎么获取到硬件模块，硬件设备的，到底是怎么加载解析动态共享库的。

上一篇我们分析了android HAL层的主要的两个结构体hw_module_t(硬件模块)和hw_device_t(硬件设备)的成员，下面我们来具体看看上层app到底是怎么实现操作硬件的？ 我们知道，一些硬件厂商不愿意将自己的一些核心代码开放出去，所以将这些代码放到HAL层，但是怎么保证它不开放呢？HAL层代码不是也让大家知道下载吗？其实硬件厂商的HAL核心代码是以共享库的形式出现的，每次在需要的时候，hal会自动加载调用相关共享库。那么是怎么加载找到某一硬件设备对应的共享库的呢？这也是我们这篇都要说的。

上层app通过jni调用hal层的hw_get_module函数获取硬件模块，这个函数是上层与hal打交道的入口。所以如果我们以程序调用执行的流程去看源码的话，这个函数就是hal层第一个被调用的函数，下面我们就 从这个函数开始，沿着程序执行的流程走下去。 hw_get_module函数定义在/hardware/libhardware/hardware.c中，打开这个文件可以看到定义如下：

1 int hw_get_module(const char *id, const struct hw_module_t **module) 2 { 3 int status; 4 int i; 5 const struct hw_module_t hmi = NULL; 6 char prop[PATH_MAX]; 7 char path[PATH_MAX]; 8 9 / 10 * Here we rely on the fact that calling dlopen multiple times on 11 * the same .so will simply increment a refcount (and not load 12 * a new copy of the library). 13 * We also assume that dlopen() is thread-safe. 14 / 15 16 / Loop through the configuration variants looking for a module / 17 for (i=0 ; i<HAL_VARIANT_KEYS_COUNT+1 ; i++) { 18 if (i < HAL_VARIANT_KEYS_COUNT) { 19 if (property_get(variant_keys[i], prop, NULL) == 0) {//获取属性 20 continue; 21 } 22 snprintf(path, sizeof(path), "%s/%s.%s.so", 23 HAL_LIBRARY_PATH1, id, prop); 24 if (access(path, R_OK) == 0) break;//检查system路径是否有库文件 25 26 snprintf(path, sizeof(path), "%s/%s.%s.so", 27 HAL_LIBRARY_PATH2, id, prop); 28 if (access(path, R_OK) == 0) break;//检查vender路径是否有库文件 29 } else { 30 snprintf(path, sizeof(path), "%s/%s.default.so",//如果都没有，则使用缺省的 31 HAL_LIBRARY_PATH1, id); 32 if (access(path, R_OK) == 0) break; 33 } 34 } 35 36 status = -ENOENT; 37 if (i < HAL_VARIANT_KEYS_COUNT+1) { 38 / load the module, if this fails, we're doomed, and we should not try 39 * to load a different variant. */ 40 status = load(id, path, module);//装载库，得到module 41 } 42 43 return status; 44 }

看第一行我们知道有两个参数，第一参数id就是要获取的硬件模块的id，第二个参数module就是我们想得到的硬件模块结构体的指针。 所以可以看出，上层首先给hal需要获取的硬件模块的id，hw_get_module函数根据这个id去查找匹配和这个id对应的硬件模块结构体的。 下面看看怎么找的。 17行有个for循环，上限是HAL_VARIANT_KEYS_COUNT+1，那么这个HAL_VARIANT_KEYS_COUNT是什么呢？查看同文件下找到有： static const int HAL_VARIANT_KEYS_COUNT = (sizeof(variant_keys)/sizeof(variant_keys[0])); 原来它是variant_keys这个数组的元素个数。那么这个数组又是什么呢？在本文件找，有：

/**

• There are a set of variant filename for modules. The form of the filename
• is "<MODULE_ID>.variant.so" so for the led module the Dream variants
• of base "ro.product.board", "ro.board.platform" and "ro.arch" would be:
• 
  
• led.trout.so
• led.msm7k.so
• led.ARMV6.so
• led.default.so */

static const char variant_keys[] = { "ro.hardware", / This goes first so that it can pick up a different file on the emulator. */ "ro.product.board", "ro.board.platform", "ro.arch" };

可以看到它其实是个字符串数组。站且不知道干什么的。继续看hw_get_module函数，进入for循环里面，看22行，其实它是将HAL_LIBRARY_PATH1, id, prop这三个串拼凑一个路径出来， HAL_LIBRARY_PATH1定义如下： /** Base path of the hal modules */ #define HAL_LIBRARY_PATH1 "/system/lib/hw" #define HAL_LIBRARY_PATH2 "/vendor/lib/hw" id是上层提供的，prop这个变量的值是前面19行property_get(variant_keys[i], prop, NULL）函数获取到的，其实这个函数是通过variant_keys数组的的属性查找到系统中对应的变种名称。不同的平台获取到prop值是不一样的。 假如在获取到的prop值是tout，需要获取的硬件模块的id是leds，那么最后path组成的串是/system/lib/hw/leds.tout.so。 后面24行access是检查这个路径下是否存在，如果有就break，跳出循环。如果没有，继续走下面， 可以看到下面几行和刚才形式差不多， snprintf(path, sizeof(path), "%s/%s.%s.so", HAL_LIBRARY_PATH2, id, prop); if (access(path, R_OK) == 0) break;//检查vender路径是否有库文件 结合 HAL_LIBRARY_PATH2 为"/vendor/lib/hw"，假设同样获取到的prop值是tout，需要获取的硬件模块的id是leds，这种情况下path拼出来的值是/vender/lib/hw/leds.tout.so,然后在判断文件是否存在。如果存在跳出循环。 从以上分析，其实这就是hal层搜索动态共享库的方式，从中我们可以得到两点： 1.动态共享库一般放在 "/system/lib/hw"和"/vendor/lib/hw"这两个路径下。 2.动态库的名称是以"id.variant.so"的形式命名的，其中id为上层提供，中间variant为变种名称，是随系统平台变化的。 接着，从29到32行我们可以看到，当所有变种名称形式的包都不存在时，就以"id.default.so"形式包名查找是否存在。 37行， if (i < HAL_VARIANT_KEYS_COUNT+1)，如果i小于变种名称数组的话，表示找到了对应的库，那么38行load(id, path, module);//装载库，得到module。

以上就对hal层搜索库的规则搞清楚了。 下一篇我们将进入load函数，看看共享库是如何被加载的。

前面分析了android HAL层是如何搜索硬件模块的动态共享库的，其实就是在"system/lib/hw/"或者"/vendor/lib/hw/"这两个路径下找到共享库modueid.variant.so后，通过调用load函数加载库。 下面我们进入load函数，看看具体是如何实现加载共享库的。 以下为load函数定义，同样在/hardware/libhardware/hardware.c中实现的。

1 /** 2 * Load the file defined by the variant and if successful 3 * return the dlopen handle and the hmi. 4 * @return 0 = success, !0 = failure. 5 */ 6 static int load(const char *id, 7 const char *path, 8 const struct hw_module_t **pHmi) 9 {//传入硬件模块id和库所在路径，获取到硬件模块结构体 10 int status; 11 void *handle; 12 struct hw_module_t hmi; 13 14 / 15 * load the symbols resolving undefined symbols before 16 * dlopen returns. Since RTLD_GLOBAL is not or'd in with 17 * RTLD_NOW the external symbols will not be global 18 */ 19 handle = dlopen(path, RTLD_NOW);//打开共享库 20 if (handle == NULL) { 21 char const err_str = dlerror(); 22 LOGE("load: module=%s\n%s", path, err_str?err_str:"unknown"); 23 status = -EINVAL; 24 goto done; 25 } 26 27 / Get the address of the struct hal_module_info. */ 28 const char *sym = HAL_MODULE_INFO_SYM_AS_STR; 29 hmi = (struct hw_module_t )dlsym(handle, sym);//解析共享库 30 if (hmi == NULL) { 31 LOGE("load: couldn't find symbol %s", sym); 32 status = -EINVAL; 33 goto done; 34 } 35 36 / Check that the id matches / 37 if (strcmp(id, hmi->id) != 0) {//匹配解析出硬件模块的id和传入我们实际想要得到的模块id是否一致 38 LOGE("load: id=%s != hmi->id=%s", id, hmi->id); 39 status = -EINVAL; 40 goto done; 41 } 42 43 hmi->dso = handle; //将打开库得到句柄传给硬件模块的dso 44 45 / success */ 46 status = 0; 47 48 done: 49 if (status != 0) { 50 hmi = NULL; 51 if (handle != NULL) { 52 dlclose(handle); 53 handle = NULL; 54 } 55 } else { 56 LOGV("loaded HAL id=%s path=%s hmi=%p handle=%p", 57 id, path, *pHmi, handle); 58 } 59 60 *pHmi = hmi;//将得到的module的结果通过第三个参数传给hw_module_t 61 62 return status; 63 }

可以看到load函数传入的几个参数，第一个参数就是需要加载的硬件模块对应动态库的硬件模块的id， 第二个参数就是动态库存放的路径，就是在hw_get_module函数前部分搜索库得到的path， 第三个参数就是我们需要得到的硬件模块结构体，通过它传给hw_get_module，hw_get_module函数在通过参数传给jni。 第19行，首先调用dlopen打开共享库，该函数通过传入的库的路径找到库，并且打开它，传回一个操作句柄handle，然后再调用dlsym函数解析这个打开的库，下面第29行，得到库中包含的硬件模块结构体，并将它返回回来。所以硬件厂商或者硬件移植者都必须根据hal的这个架构去实现填充这个和自己硬件相关的硬件模块结构体hw_module_t，供使用。 通过dlsym解析之后就得到了hw_module_t，随后第37行，将从库中解析得到的结构体中的id和传入的id做比较，看是否一致。 如果一致则证明就是得到正确的硬件模块了。 最后第60行，将hw_module_t结构体指针传给第三个参数，传给hw_get_module函数。 到此，hw_get_module函数就得到了硬件模块结构体hw_module_t. 有了hw_module_t,那么通过其内部的method open就能打开硬件模块对应的设备了，通过结构体中的一些方法就能操作硬件设备了。