26
2017
09

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

.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 “.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的值加载对应的动态链接库。如果没有读取到任何属性值,则使用.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.”获取属性值,如果存在,则作为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为例:
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得到硬件的接口函数。

作者:诺远
链接:http://www.jianshu.com/p/0d155f267589
來源:简书
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

上一篇:新建Maven项目流程表 下一篇:View和输入法的通信原理