Android HAL概述
Android HAL(Hardware Abstract Layer)硬件抽象层，从字面意思可以看出是对硬件设备的抽象和封装，为Android在不同硬件设备提供统一的访问接口。HAL处于Android framework和Linux kernel driver之间，HAL存在的意义有以下2个方面：
- HAL屏蔽了不同硬件设备的差异，为Android提供了统一的访问硬件设备的接口。不同的硬件厂商遵循HAL标准来实现自己的硬件控制逻辑，但开发者不必关心不同硬件设备的差异，只需要按照HAL提供的标准接口访问硬件就可以了。
- HAL层帮助硬件厂商隐藏了设备相关模块的核心细节。硬件厂商处于利益考虑，不希望公开硬件设备相关的实现细节；有了HAL层之后，他们可以把一些核心的算法之类的东西的实现放在HAL层，而HAL层位于用户空间，不属于linux内核，和android源码一样遵循的是Apache license协议，这个是可以开源或者不开的。
搞清楚了HAL存在的作用，就可以对其框架做个简单的总结。这里从以下3个方面来简单分析下HAL架构，以备后忘。
- 分析HAL的2个核心数据结构：hw_module_t 和 hw_device_t；
- 描述HAL是如何查询和加载设备动态共享库的；
- 以GPS为例，简单分析上层是如何使用HAL来访问硬件设备的。
以Android 6.0 源码为基础，对HAL框架进行分析。
hw_module_t和hw_device_t
Android HAL将各类硬件设备抽象为硬件模块，HAL使用hw_module_t结构体描述一类硬件抽象模块。每个硬件抽象模块都对应一个动态链接库，一般是由厂商提供的，这个动态链接库必须尊重HAL的命名规范才能被HAL加载到，我们后面会看到。
每一类硬件抽象模块又包含多个独立的硬件设备，HAL使用hw_device_t结构体描述硬件模块中的独立硬件设备。
因此，hw_module_t和hw_device_t是HAL中的核心数据结构，这2个结构体代表了HAL对硬件设备的抽象逻辑。我们第一步先来分析下这2个核心数据结构。
hw_module_t定义在/hardware/libhardware/include/hardware/hardware.h文件中：
/**
* 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;
/**
* The API version of the implemented module. The module owner is
* responsible for updating the version when a module interface has
* changed.
*
* The derived modules such as gralloc and audio own and manage this field.
* The module user must interpret the version field to decide whether or
* not to inter-operate with the supplied module implementation.
* For example, SurfaceFlinger is responsible for making sure that
* it knows how to manage different versions of the gralloc-module API,
* and AudioFlinger must know how to do the same for audio-module API.
*
* The module API version should include a major and a minor component.
* For example, version 1.0 could be represented as 0x0100. This format
* implies that versions 0x0100-0x01ff are all API-compatible.
*
* In the future, libhardware will expose a hw_get_module_version()
* (or equivalent) function that will take minimum/maximum supported
* versions as arguments and would be able to reject modules with
* versions outside of the supplied range.
*/
uint16_t module_api_version;
#define version_major module_api_version
/**
* version_major/version_minor defines are supplied here for temporary
* source code compatibility. They will be removed in the next version.
* ALL clients must convert to the new version format.
*/
/**
* The API version of the HAL module interface. This is meant to
* version the hw_module_t, hw_module_methods_t, and hw_device_t
* structures and definitions.
*
* The HAL interface owns this field. Module users/implementations
* must NOT rely on this value for version information.
*
* Presently, 0 is the only valid value.
*/
uint16_t hal_api_version;
#define version_minor hal_api_version
/** Identifier of module */
const char *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;
#ifdef __LP64__
uint64_t reserved[32-7];
#else
/** padding to 128 bytes, reserved for future use */
uint32_t reserved[32-7];
#endif
} hw_module_t;
- 注释里面规定，每个硬件模块必须包含一个名字为HAL_MODULE_INFO_SYM的结构体；这个结构体的第一个元素必须为hw_module_t，然后后面可以增加模块相关的其他信息。这里可以理解为是一种继承关系，相当于应硬件模块的HAL_MODULE_INFO_SYM结构体，继承了hw_module_t，只不过是C语言中没有继承的概念，是通过在结构体中包含的方式间接实现的。
HAL_MODULE_INFO_SYM值定义同样在hardware.h中：
/**
* Name of the hal_module_info
*/
#define HAL_MODULE_INFO_SYM HMI
/**
* Name of the hal_module_info as a string
*/
#define HAL_MODULE_INFO_SYM_AS_STR "HMI"
- tag: 必须被初始化HARDWARE_MODULE_TAG常量，其定义在hardware.h中：
/*
* Value for the hw_module_t.tag field
*/
#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')
- version相关信息，不多说
- 紧跟着是模块id，name，author,看名字就知道意思了。
- dso：用来保存加载硬件抽象模块后得到的句柄值，前面提到每一个硬件抽象模块都对应一个动态链接库，硬件抽象模块的加载过程实际是使用dlopen函数打开对应的动态链接库文件获得这个句柄；使用dlclose函数进行硬件抽象模块的卸载是需要用到这个句柄，因此需要保存起来。
- struct hw_module_methods_t* methods：看名字应该是操作该硬件模块的方法。hw_module_methods_t定义在hardware.h，如下：
typedef struct hw_module_methods_t {
/** Open a specific device */
int (*open)(const struct hw_module_t* module, const char* id,
struct hw_device_t** device);
} hw_module_methods_t;
我们看到，hw_module_methods_t只有一个函数指针open，根据参数可以推断出open是用来打开硬件模块获取模块中的硬件设备。由于一个硬件抽象模块中可能包含多个设备，因此需要根据传入的设备id来获取相应的硬件设备he_device_t。所以这里的device就表示一个已经打开的硬件设备。
下面来看看hw_device_t结构体的定义：hardware.h
/**
* Every device data structure must begin with hw_device_t
* followed by module specific public methods and attributes.
*/
typedef struct hw_device_t {
/** tag must be initialized to HARDWARE_DEVICE_TAG */
uint32_t tag;
/**
* Version of the module-specific device API. This value is used by
* the derived-module user to manage different device implementations.
*
* The module user is responsible for checking the module_api_version
* and device version fields to ensure that the user is capable of
* communicating with the specific module implementation.
*
* One module can support multiple devices with different versions. This
* can be useful when a device interface changes in an incompatible way
* but it is still necessary to support older implementations at the same
* time. One such example is the Camera 2.0 API.
*
* This field is interpreted by the module user and is ignored by the
* HAL interface itself.
*/
uint32_t version;
/** reference to the module this device belongs to */
struct hw_module_t* module;
/** padding reserved for future use */
#ifdef __LP64__
uint64_t reserved[12];
#else
uint32_t reserved[12];
#endif
/** Close this device */
int (*close)(struct hw_device_t* device);
} hw_device_t;
- HAL规定每个硬件设备都必须定义一个硬件设备描述结构体，该结构体必须以hw_device_t作为第一个成员变量，后跟设备相关的公开函数和属性。
- tag：初始化为常量HARDWARE_DEVICE_TAG
- module：表示该硬件设备归属于哪一个硬件抽象模块。
- close：函数指针，用来关闭硬件设备。
到此，HAL的2个核心数据结构体就分析完了；硬件厂商必须遵循HAL规范和命名，实现这2个结构体：抽象硬件模块结构体和抽象硬件设备结构体；并且提供open函数来获取hw_device_t。下面我来看HAL到底是怎样获取硬件模块和硬件设备的，是如何加载和解析对应的动态共享库的。
HAL模块的加载
我们知道每个硬件抽象模块都对应一个动态链接库，这个是厂商提供的，存放在默认的路径下；HAL在需要的时候会去匹配和加载动态链接库。那么HAL是如何找到某个硬件模块对应的正确的共享库呢？
首先，每个模块对应的动态链接库的名字是遵循HAL的命名规范的。举例说明，以GPS模块为例，典型的共享库名字如下：
gps.mt6753.so
<MODULE_ID>.variant.so
- ro.hardware
- ro.product.board
- ro.board.platform
- ro.arch
硬件抽象模块的动态链接库文件名命名规范定义在：/hardware/libhardware/hardware.c：
/**
* 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"
};
//后面会用到
static const int HAL_VARIANT_KEYS_COUNT =
(sizeof(variant_keys)/sizeof(variant_keys[0]));
HAL会按照variant_keys[]定义的属性名称的顺序逐一来读取属性值，若值存在，则作为variant的值加载对应的动态链接库。如果没有读取到任何属性值，则使用<MODULE_ID>.default.so 作为默认的动态链接库文件名来加载硬件模块。
有了模块的文件名字规范，那么共享库的存放路径也是有规范的。HAL规定了2个硬件模块动态共享库的存放路径，定义在/hardware/libhardware/hardware.c：
/** Base path of the hal modules */
#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, /hardware/libhardware/hardware.c:
/*
* Check if a HAL with given name and subname exists, if so return 0, otherwise
* otherwise return negative. On success path will contain the path to the HAL.
*/
static int hw_module_exists(char *path, size_t path_len, const char *name,
const char *subname)
{
//检查/vendor/lib/hw路径下是否存在目标模块
snprintf(path, path_len, "%s/%s.%s.so",
HAL_LIBRARY_PATH2, name, subname);
if (access(path, R_OK) == 0)
return 0;
//检查/system/lib/hw路径下是否存在目标模块
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
现在我们知道了HAL是如何命名和存放模块共享库的，以及HAL基于这种机制来检查目标模块库是否存在的方法。下面来看上传framework打开和加载模块共享库的具体实现过程。
上传framework和应用打开HAL库的入口函数为hw_get_module,定义如下hardware/libhardware/include/hardware/hardware.h：
/**
* Get the module info associated with a module by id.
*
* @return: 0 == success, <0 == error and *module == NULL
*/
int hw_get_module(const char *id, const struct hw_module_t **module);
- 传入目标模块的唯一id，得到表示该模块的hw_module_t结构体指针
具体实现在文件hardware/libhardware/hardware.c，下面我们具体来分析。
int hw_get_module(const char *id, const struct hw_module_t **module)
{
return hw_get_module_by_class(id, NULL, module);
}
hw_get_module实际上调用了hw_get_module_by_class来执行实际的工作。
int hw_get_module_by_class(const char *class_id, const char *inst,
const struct hw_module_t **module)
{
int i = 0;
char prop[PATH_MAX] = {0};
char path[PATH_MAX] = {0};
char name[PATH_MAX] = {0};
char prop_name[PATH_MAX] = {0};
//根据id生成module name，这里inst为NULL
if (inst)
snprintf(name, PATH_MAX, "%s.%s", class_id, inst);
else
strlcpy(name, class_id, PATH_MAX);
/*
* Here we rely on the fact that calling dlopen multiple times on
* the same .so will simply increment a refcount (and not load
* a new copy of the library).
* We also assume that dlopen() is thread-safe.
*/
/* First try a property specific to the class and possibly instance */
//首先查询特定的属性名称来获取variant值
snprintf(prop_name, sizeof(prop_name), "ro.hardware.%s", name);
if (property_get(prop_name, prop, NULL) > 0) {
//检查目标模块共享库是否存在
if (hw_module_exists(path, sizeof(path), name, prop) == 0) {
goto found; //存在，找到了
}
}
/* Loop through the configuration variants looking for a module */
//逐一查询variant_keys数组定义的属性名称
for (i=0 ; i<HAL_VARIANT_KEYS_COUNT; i++) {
if (property_get(variant_keys[i], prop, NULL) == 0) {
continue;
}
//检查目标模块共享库是否存在
if (hw_module_exists(path, sizeof(path), name, prop) == 0) {
goto found;
}
}
//没有找到，尝试默认variant名称为default的共享库
/* Nothing found, try the default */
if (hw_module_exists(path, sizeof(path), name, "default") == 0) {
goto found;
}
return -ENOENT;
found:
/* load the module, if this fails, we're doomed, and we should not try
* to load a different variant. */
return load(class_id, path, module); //执行加载和解析共享库的工作
}
- 首先根据class_id生成module name，这里就是hw_get_module函数传进来的id；
- 根据属性名称“ro.hardware.<id>”获取属性值，如果存在，则作为variant值调用前面提到的hw_module_exits检查目标是否存在。如果存在，执行load。
- 如果不存在，则遍历variant_keys数组中定义的属性名称来获取属性值，得到目标模块库名字，检查其是否存在；
- 如果根据属性值都没有找到模块共享库，则尝试检查default的库是否存在；如果仍然不存在，返回错误。
- 如果上述任何一次尝试找到了目标共享库，path就是目标共享库的文件路径，调用load执行真正的加载库的工作。
下面来看load函数：
/**
* Load the file defined by the variant and if successful
* return the dlopen handle and the hmi.
* @return 0 = success, !0 = failure.
*/
static int load(const char *id,
const char *path,
const struct hw_module_t **pHmi)
{
int status = -EINVAL;
void *handle = NULL;
struct hw_module_t *hmi = NULL;
/*
* load the symbols resolving undefined symbols before
* dlopen returns. Since RTLD_GLOBAL is not or'd in with
* RTLD_NOW the external symbols will not be global
*/
//使用dlopen打开path定义的目标共享库，得到库文件的句柄handle
handle = dlopen(path, RTLD_NOW);
if (handle == NULL) {
//出错，通过dlerror获取错误信息
char const *err_str = dlerror();
ALOGE("load: module=%s\n%s", path, err_str?err_str:"unknown");
status = -EINVAL;
goto done;
}
/* Get the address of the struct hal_module_info. */
const char *sym = HAL_MODULE_INFO_SYM_AS_STR; //"HMI"
//使用dlsym找到符号为“HMI”的地址，这里应该是hw_module_t结构体的地址；并且赋给hmi
hmi = (struct hw_module_t *)dlsym(handle, sym);
if (hmi == NULL) {
ALOGE("load: couldn't find symbol %s", sym);
status = -EINVAL;
goto done;
}
/* Check that the id matches */
//检查模块id是否匹配
if (strcmp(id, hmi->id) != 0) {
ALOGE("load: id=%s != hmi->id=%s", id, hmi->id);
status = -EINVAL;
goto done;
}
//保存共享库文件的句柄
hmi->dso = handle;
/* success */
status = 0;
done:
if (status != 0) {
hmi = NULL;
if (handle != NULL) {
dlclose(handle);
handle = NULL;
}
} else {
ALOGV("loaded HAL id=%s path=%s hmi=%p handle=%p",
id, path, *pHmi, handle);
}
//返回得到的hw_module_t结构体的指针
*pHmi = hmi;
return status;
}
- load函数的主要工作时通过dlopen来打开目标模块共享库，打开成功后，使用dlsym来得到符号名字为"HMI"的地址。这里的HMI应该是模块定义的hw_module_t结构体的名字，如此，就得到了模块对应的hw_module_t的指针。
至此，我么终于得到了表示硬件模块的hw_module_t的指针，有了这个指针，就可以对硬件模块进行操作了。HAL是如何查找和加载模块共享库的过程就分析完了，最终还是通过dlopen和dlsym拿到了模块的hw_module_t的指针，就可以为所欲为了。
GPS HAL加载过程
前面分析完了HAL的框架和机制，以GPS HAL的加载过程为例把上面的知识串起来。我们从framework层的hw_get_module函数作为入口点，初步拆解分析。
加载GPS HAL的入口函数定义在frameworks/base/services/core/jni/com_android_server_location_GpsLocationProvider.cpp：
static void android_location_GpsLocationProvider_class_init_native(JNIEnv* env, jclass clazz) {
// skip unrelate code
hw_module_t* module;
//获取GPS模块的hw_module_t指针
err = hw_get_module(GPS_HARDWARE_MODULE_ID, (hw_module_t const**)&module);
if (err == 0) {
hw_device_t* device;
//调用open函数得到GPS设备的hw_device_t指针
err = module->methods->open(module, GPS_HARDWARE_MODULE_ID, &device);
if (err == 0) {
//指针强转为gps_device_t类型
gps_device_t* gps_device = (gps_device_t *)device;
//得到GPS模块的inteface接口，通过sGpsInterface就可以操作GPS设备了
sGpsInterface = gps_device->get_gps_interface(gps_device);
}
}
- GPS_HARDWARE_MODULE_ID定义在hardware/libhardware/include/hardware/gps.h中：
/**
* The id of this module
*/
#define GPS_HARDWARE_MODULE_ID "gps"
- 调用hw_get_module得到GPS模块的hw_module_t指针，保存在module变量中；我们来看下GPS模块的hw_module_t长得什么样。以hardware/qcom/gps/loc_api/libloc_api_50001/gps.c为例：
- hw_get_module方法返回的最终是下面的实例
struct hw_module_t HAL_MODULE_INFO_SYM = {
.tag = HARDWARE_MODULE_TAG,
.module_api_version = 1,
.hal_api_version = 0,
.id = GPS_HARDWARE_MODULE_ID,
.name = "loc_api GPS Module",
.author = "Qualcomm USA, Inc.",
.methods = &gps_module_methods, //自定义的函数指针，这里既是获取hw_device_t的入口了
};
- 接着调用GPS模块自定义的hw_module_t的methods中的open函数，获取hw_device_t指针。上面的代码中我们看到，GPS模块的hw_module_t的methods成员的值为
gps_module_methods,其定义如下：
static struct hw_module_methods_t gps_module_methods = {
.open = open_gps
};
OK，我们来看open_gps函数做了什么：
static int open_gps(const struct hw_module_t* module, char const* name,
struct hw_device_t** device)
{
//为gps_device_t分配内存空间
struct gps_device_t *dev = (struct gps_device_t *) malloc(sizeof(struct gps_device_t));
if(dev == NULL)
return -1;
memset(dev, 0, sizeof(*dev));
//为gps_device_t的common成员变量赋值
dev->common.tag = HARDWARE_DEVICE_TAG;
dev->common.version = 0;
dev->common.module = (struct hw_module_t*)module;
//通过下面的函数就能得到GPS模块所有interface
dev->get_gps_interface = gps__get_gps_interface;
//将gps_device_t指针强转为hw_device_t指针，赋给device
*device = (struct hw_device_t*)dev;
return 0;
}
我们看到open_gps创建了gps_device_t结构体，初始化完成后，将其转为hw_device_t。所以module->methods->open得到实际上是gps_device_t结构体指针。这里我们可以理解为gps_device_t是hw_device_t的子类，将子类对象转为父类对象返回，是很正常的使用方法。为什么可以这么理解，看一下gps_device_t长得什么样子就明白了。
hardware/libhardware/include/hardware/gps.h：
struct gps_device_t {
struct hw_device_t common;
/**
* Set the provided lights to the provided values.
*
* Returns: 0 on succes, error code on failure.
*/
const GpsInterface* (*get_gps_interface)(struct gps_device_t* dev);
};
啊哈，第一个成员是名为common的hw_device_t类型的变量；所以可以理解为gps_device_t继承了hw_device_t。
- 得到GPS的hw_device_t指针后将其强转回gps_devcie_t指针，然后调用GPS device定义的
get_gps_interface接口，得到保存GPS 接口的GpsInterface结构体指针。
在open_gps中，get_gps_interface被赋值为gps__get_gps_interface函数指针，其主要工作就是返回GPS模块的GpsInterface结构体指针。
GpsInterface定义在hardware/libhardware/include/hardware/gps.h：
/** Represents the standard GPS interface. */
typedef struct {
/** set to sizeof(GpsInterface) */
size_t size;
/**
* Opens the interface and provides the callback routines
* to the implementation of this interface.
*/
int (*init)( GpsCallbacks* callbacks );
/** Starts navigating. */
int (*start)( void );
/** Stops navigating. */
int (*stop)( void );
/** Closes the interface. */
void (*cleanup)( void );
/** Injects the current time. */
int (*inject_time)(GpsUtcTime time, int64_t timeReference,
int uncertainty);
/** Injects current location from another location provider
* (typically cell ID).
* latitude and longitude are measured in degrees
* expected accuracy is measured in meters
*/
int (*inject_location)(double latitude, double longitude, float accuracy);
/**
* Specifies that the next call to start will not use the
* information defined in the flags. GPS_DELETE_ALL is passed for
* a cold start.
*/
void (*delete_aiding_data)(GpsAidingData flags);
/**
* min_interval represents the time between fixes in milliseconds.
* preferred_accuracy represents the requested fix accuracy in meters.
* preferred_time represents the requested time to first fix in milliseconds.
*
* 'mode' parameter should be one of GPS_POSITION_MODE_MS_BASE
* or GPS_POSITION_MODE_STANDALONE.
* It is allowed by the platform (and it is recommended) to fallback to
* GPS_POSITION_MODE_MS_BASE if GPS_POSITION_MODE_MS_ASSISTED is passed in, and
* GPS_POSITION_MODE_MS_BASED is supported.
*/
int (*set_position_mode)(GpsPositionMode mode, GpsPositionRecurrence recurrence,
uint32_t min_interval, uint32_t preferred_accuracy, uint32_t preferred_time);
/** Get a pointer to extension information. */
const void* (*get_extension)(const char* name);
} GpsInterface;
- GpsInterface定义了操作GPS模块的基本的标准接口，得到了GpsInterface就可以通过这些接口操作GPS了，终于可以硬件打交道了。某一个具体的GPS模块会将GpsInterface中的接口初始化为其平台相关的具体实现。比如：hardware/qcom/gps/loc_api/libloc_api_50001/loc.cpp
// Defines the GpsInterface in gps.h
static const GpsInterface sLocEngInterface =
{
sizeof(GpsInterface),
loc_init,
loc_start,
loc_stop,
loc_cleanup,
loc_inject_time,
loc_inject_location,
loc_delete_aiding_data,
loc_set_position_mode,
loc_get_extension
};
到这里，整个GPS HAL的加载过程就结束了，后面就可以通过GpsInterface操作GPS模块了。
本文分析了Android HAL的框架和机制，介绍了它的2个核心数据结构，分析了硬件模块的查询和加载过程；然后以GPS为例走了说明了如何通过HAL得到硬件的接口函数。