HAL so库加载机制---之一
1,概述
Android HAL(Hardware Abstract Layer)硬件抽象层，从字面意思可以看出是对硬件设备的抽象和封装，
为Android在不同硬件设备提供统一的访问接口。HAL处于Android framework和Linux kernel driver之间，
HAL存在的意义有以下2个方面：
1，HAL屏蔽了不同硬件设备的差异，为Android提供了统一的访问硬件设备的接口。
不同的硬件厂商遵循HAL标准来实现自己的硬件控制逻辑，但开发者不必关心不同硬件设备的差异，
只需要按照HAL提供的标准接口访问硬件就可以了。
2，HAL层帮助硬件厂商隐藏了设备相关模块的核心细节。硬件厂商处于利益考虑，不希望公开硬件设备相关的实现细节；
有了HAL层之后，他们可以把一 些核心的算法之类的东西的实现放在HAL层，而HAL层位于用户空间，不属于linux内核，
和android源码一样遵循的是Apache license协议，这个是可以开源或者不开的。
搞清楚了HAL存在的作用，就可以对其框架做个简单的总结。这里从以下3个方面来简单分析下HAL架构.
1,分析HAL的2个核心数据结构：hw_module_t 和 hw_device_t；
2,描述HAL是如何查询和加载设备动态共享库的；
3,以GPS为例，简单分析上层是如何使用HAL来访问硬件设备的。
本文基于android 6.0。
2, 数据结构
hw_module_t结构体:Android HAL将各类硬件设备抽象为硬件模块，HAL使用该结构体描述一类硬件抽象模块。
每个硬件抽象模块都对应一个动态链接库，一般是由厂商提供的，这个动态链接库必须尊重HAL的命名规范才能被HAL加载到，后面会看到。
hw_device_t结构体:每一类硬件抽象模块又包含多个独立的硬件设备，HAL使用该结构体描述硬件模块中的独立硬件设备。
2.1 hw_module_t
hardware.h文件中的hw_module_t结构体定义如下，
typedef struct hw_module_t {
uint32_t tag;
uint16_t module_api_version;
#define version_major module_api_version
uint16_t hal_api_version;
#define version_minor hal_api_version
const char *id;
const char *name;
const char *author;
struct hw_module_methods_t* methods;
void* dso;
#ifdef __LP64__
uint64_t reserved[32-7];
#else
uint32_t reserved[32-7];
#endif
} hw_module_t;
注意:
1, 每个硬件模块必须包含一个名字为HAL_MODULE_INFO_SYM的结构体；
这个结构体的第一个元素必须为hw_module_t，然后后面可以增加模块相关的其他信息。
这里可以理解为是一种继承关系，相当于应硬件模块的HAL_MODULE_INFO_SYM结构体，继承了hw_module_t，
只不过是C语言中没有继承的概念，是通过在结构体中包含的方式间接实现的。
HAL_MODULE_INFO_SYM值定义同样在hardware.h中：
#define HAL_MODULE_INFO_SYM HMI
#define HAL_MODULE_INFO_SYM_AS_STR "HMI"
2, tag必须被初始化HARDWARE_MODULE_TAG常量，其定义如下,
#define MAKE_TAG_CONSTANT(A,B,C,D) (((A) << 24) | ((B) << 16) | ((C) << 8) | (D))
#define HARDWARE_MODULE_TAG MAKE_TAG_CONSTANT('H', 'W', 'M', 'T')
#define HARDWARE_DEVICE_TAG MAKE_TAG_CONSTANT('H', 'W', 'D', 'T')
3，dso：用来保存加载硬件抽象模块后得到的句柄值，前面提到每一个硬件抽象模块都对应一个动态链接库，
硬件抽象模块的加载过程实际是使用dlopen函数打开对应的动态链接库文件获得这个句柄；
使用dlclose函数进行硬件抽象模块的卸载是需要用到这个句柄，因此需要保存起来。
4, hw_module_methods_t结构体方法定义如下,
typedef struct hw_module_methods_t {
int (*open)(const struct hw_module_t* module, const char* id,
struct hw_device_t** device);
} hw_module_methods_t;
该结构体只有一个函数指针open，打开硬件模块获取模块中的硬件设备。由于一个硬件抽象模块中可能包含多个设备，
因此需要根据传入的设备id来获取相应的硬件设备he_device_t。所以这里的device就表示一个已经打开的硬件设备。
2.2 hw_device_t
hardware.h文件中的hw_device_t结构体定义如下，
typedef struct hw_device_t {
uint32_t tag;
uint32_t version;
struct hw_module_t* module;
#ifdef __LP64__
uint64_t reserved[12];
#else
uint32_t reserved[12];
#endif
int (*close)(struct hw_device_t* device);
} hw_device_t;
module：表示该硬件设备归属于哪一个硬件抽象模块。
close：函数指针，用来关闭硬件设备。
小结:到此，HAL的2个核心数据结构体就分析完了；硬件厂商必须遵循HAL规范和命名，实现hw_module_t结构体；
并且提供open函数来获取hw_device_t。下面看看HAL到底是怎样获取硬件模块和硬件设备的，是如何加载和解析对应的动态共享库的。
3, HAL库规范
HAL会按照variant_keys[]定义的属性名称的顺序逐一来读取属性值，若值存在，
则作为variant的值加载对应的动态链接库。如果没有读取到任何属性值，
则使用
hardware.c文件中的variant_keys定义如下，
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"
};
variant_keys中模块名个数,逐个查找。
static const int HAL_VARIANT_KEYS_COUNT =
(sizeof(variant_keys)/sizeof(variant_keys[0]));
有了模块的文件名字规范，那么共享库的存放路径也是有规范的。HAL规定了2个硬件模块动态共享库的存放路径，
#if defined(__LP64__)
#define HAL_LIBRARY_PATH1 "/system/lib64/hw"
#define HAL_LIBRARY_PATH2 "/vendor/lib64/hw"
#else
#define HAL_LIBRARY_PATH1 "/system/lib/hw"
#define HAL_LIBRARY_PATH2 "/vendor/lib/hw"
#endif
也就是说硬件模块的共享库必须放在/system/lib/hw 或者 /vendor/lib/hw 这2个路径下的其中一个。
HAL在加载所需的共享库的时候，会先检查HAL_LIBRARY_PATH2路径下面是否存在目标库；
如果没有，继续检查HAL_LIBRARY_PATH1路径下面是否存在。具体实现在hw_module_exists方法中,如下,
static int hw_module_exists(char *path, size_t path_len, const char *name, const char *subname)
{
snprintf(path, path_len, "%s/%s.%s.so", HAL_LIBRARY_PATH2, name, subname);
if (access(path, R_OK) == 0)
return 0;
snprintf(path, path_len, "%s/%s.%s.so",HAL_LIBRARY_PATH1, name, subname);
if (access(path, R_OK) == 0)
return 0;
return -ENOENT;
}
name：其实对应上面提到的MODULE_ID
subname: 对应从上面提到的属性值variant