Android硬件抽象层模块编写规范
Posted
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了Android硬件抽象层模块编写规范相关的知识，希望对你有一定的参考价值。
参考技术A 硬件抽象层模块编写规范硬件抽象层最终都会生成.so文件，放到系统对应的目录中。在系统使用的时候，系统会去对应目录下加载so文件，实现硬件抽象层的功能。因此硬件抽象层的加载过程就是我们使用so的一个接口。先了解加载过程从源头了解抽象层模块儿的编写规范。
1、硬件抽象层加载过程
系统在加载so的过程中，会去两个目录下查找对应id的so文件。这两个目录分别是/system/lib/hw和/vendor/lib/hw。
so文件的名字分为两个部分例如id.prop.so，第一部分是模块id。第二部分是系统prop的值，获取顺序为“ro.hardware”、“ro.producat.board”、“ro.board.platform”、“ro.arch”，如果prop都找不到的话，就用default。（不是找不到prop的值，是找不到prop值对应的so文件）。
负责加载硬件抽象层模块的函数是hw_get_module，所在的文件是/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
/**
* 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]));
/**
* 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;
void *handle;
struct hw_module_t *hmi;
/*
* 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
*/
handle = dlopen(path, RTLD_NOW);
if (handle == NULL)
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 = (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 */
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);
*pHmi = hmi;
return status;
/*
* 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)
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;
int hw_get_module_by_class(const char *class_id, const char *inst,
const struct hw_module_t **module)
int i;
char prop[PATH_MAX];
char path[PATH_MAX];
char name[PATH_MAX];
char prop_name[PATH_MAX];
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 */
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 */
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;
/* 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);
int hw_get_module(const char *id, const struct hw_module_t **module)
return hw_get_module_by_class(id, NULL, module);
找到so文件之后，调用方法load方法去加载对应的so文件，并返回hw_module_t结构体。load方法源码在上面程序中。
load方法首先调用dlopen加载对应的so文件到内存中。然后用dlsym方法找到变量HAL_MODULE_INFO_SYM_AS_STR符号对应的地址，这个地址也就是一个hw_module_t结构体，然后从这个结构体中拿出id比对load方法出入的id是否一致，如果是的话表示打开成功。加载过程完成。
HAL_MODULE_INFO_SYM_AS_STR这个符号值为HMI，也就是必须要保证这个符号之后是一个hw_module_t。接下来的规范中有这个要求。
到此，模块加载完成
2、硬件抽象层模块编写规范
硬件抽象层有两个结构体，一个是hw_module_t和hw_device_t，定义在hardware.h中。
首先说一下hw_module_t的编写规范。
1、必须要有一个“自定义硬件抽象层结构体”，且结构体第一个变量类型要为hw_module_t。
2、必须存在一个HARDWARE_MODULE_INFO_TAG的符号，且指向“自定义硬件抽象层结构体”。在加载的时候根据这个符号找到地址，并把地址的转变为hw_module_t，这也是为什么第一条中hw_module_t必须要在第一个的原因。
3、hw_module_t的tag必须为HARDWARE_MODULE_TAG
4、结构体中要有一个方法列表，其中要有一个open方法。用open方法获得hw_device_t
接下来说一下hw_device_t的编写规范
1、必须要有一个“自定义硬件设备结构体”，且结构体第一个变量类型要为hw_device_t。
2、hw_device_t的tag必须为HARDWARE_DEVICE_TAG
3、要有一个close函数指针，来关闭设备
按照上面规范编写的硬件抽象层就可以由系统加载并正确获取到device。具体的应用层逻辑在device中实现。
Android HAL硬件抽象层的原理与应用实例
文章目录
前言
先来看下 Android 的系统架构图：
HAL 全称 Hardware Abstract Layer，即硬件抽象层，它向下屏蔽了硬件的实现细节，向上提供了抽象接口，HAL是底层硬件和上层框架直接的接口，框架层通过HAL可以操作硬件设备。
为什么需要HAL？
许多早期的计算机系统没有任何形式的硬件抽象，这意味着为该系统编写程序的任何人都必须知道每个硬件设备如何与系统的其余部分进行通信。这对软件开发人员来说是一个巨大的挑战，因为他们必须知道系统中每个硬件设备如何工作才能确保软件的兼容性。使用硬件抽象，而不是直接与硬件设备通信的程序，它将程序传达给操作系统该设备应执行的操作，然后操作系统会向该设备生成硬件相关的指令。这意味着程序员不需要知道特定设备的工作方式，就能使他们的程序与设备兼容。
我们知道 Android 是基于 Linux 进行开发的，传统的 Linux 对硬件的操作基本上都是在内核中，而 Android 把对硬件的操作分为了两部分，HAL 和内核驱动，HAL 实现在用户空间，驱动在内核空间。这是因为 Linux 内核中的代码是需要开源的（遵循GUN License），如果把对硬件的操作放在内核这会损害硬件厂商的利益，因为这是别人厂商的商业机密，而现在有了 HAL 层位于用户空间（该部分代码遵循Apache License，无需对外开放源代码），硬件厂商就可以将自己的核心算法之类的放在 HAL 层，保护了自己的利益，这样 Android 系统才能得到更多厂商的支持。
Windows 下的 HAL 位于操作系统的最底层，它直接操作物理硬件设备，使用抽象接口来隔离不同硬件的具体实现，为上层的操作系统和设备驱动程序提供一个统一接口，起到对硬件抽象作用。Linux 下的 HAL 与 Windows 不同，HAL 层并不位于操作系统的最底层直接操作硬件，而是在操作系统内核层和驱动程序之上，是一个运行在 User Space(用户空间) 的服务程序。
安卓源码编译
参考文章：
- Android 系统开发系列（1）：Android 12 源代码下载、编译和刷机；
- [原创]源码编译（1）——Android6.0源码编译详解 ;
- 从谷歌官网下载android 6.0源码、编译并刷入nexus 6p手机。
HAL体系结构
HAL 层的源码目录主要如下：
1）一般除了以下3个以外都是硬件厂商相关的 hal 目录：
/hardware/libhardware_legacy/ 旧的架构、采取链接库模块的方式
/hardware/libhardware 新架构，调整为 HAL stub
/hardware/ril 无线电抽象层
2）libhardware 目录的结构如下:
/hardware/libhardware/hardware.c 编译成libhardware.s置于/system/lib
3）/hardware/libhardware/include/hardware目录下包含如下头文件：
hardware.h 通用硬件模块头文件
copybit.h copybit模块头文件
gralloc.h gralloc模块头文件
lights.h 背光模块头文件
overlay.h overlay模块头文件
qemud.h qemud模块头文件
sensors.h 传感器模块头文件
4）/hardware/libhardware/modules 目录下定义了很多硬件模块:
hardware/msm7k
/hardware/qcom
/hardware/ti
/device/Samsung
/device/moto
这些硬件模块都编译成xxx.xxx.so，目标位置为/system/lib/hw目录
HAL新老架构
位于 libhardware_legacy 目录下的 “旧HAL架构” 和位于 libhardware 目录下的 “新HAL架构”，两种框架如下图所示：
1、老式 Module 架构
Android 用户应用程序或框架层代码由 Java 实现，Java 运行在 Dalvik 虚拟机中，没有办法直接访问底层硬件，只能通过调用 so 本地库代码实现，在 so本地库代码里有对底层硬件操作代码。也就是说，应用层或框架层 Java 代码，通过 JNI 技术调用 C 或 C++ 写的 so 库代码，在 so 库代码中调用底层驱动，实现上层应用的提出的硬件请求操作。实现硬件操作的 so 库为：module。
老的 libhardware_legacy 架构，在 so 动态链接库中实现了对驱动的访问逻辑处理，应用或者框架在 Runtime（JNI 部份）通过 so 动态链接库直接调用函数达到对硬件驱动的访问。
这种设计架构虽然满足了 Java 应用访问硬件的需要，但是它使得我们的代码上下层次间的耦合太高，用户程序或框架代码必须要去加载 module 库，如果底层硬件有变化，moudle 要重新编译，上层也要做相应的变化；同时如果多个应用程序同时访问硬件，都去加载 module，则同一 module 被多个进程映射多次，会有代码的重入问题。因此 Google 又提出了新的HAL架构。
2、新式 HAL Stub 架构
新的架构使用的是 Module Stub 方式，Stub 是存根或桩的意思，其实说白了就是指一个对象代表的意思。由上面的架构可知，上层应用层或框架层代码加载 so 库代码，so 库代码我们称为 module，在 HAL 层注册了每个硬件对象的存根 stub，当上层需要访问硬件的时候，就从当前注册的硬件对象 stub 里查找，找到之后 stub 会向上层 module 提供该硬件对象的 operations interface（操作接口），该操作接口就保存在了 module 中，上层应用或框架再通过这个 module 操作接口来访问硬件。
libhardware 架构采用 Proxy 代理模式，Stub 虽然仍是以*.so的形式存在，但是 HAL 已经将*.的具体实现隐藏了起来。Stub 向 HAL 提供 operations 方法，Runtime 通过 Stub 提供的 so 获取它的 operations 方法，并告知 Runtime 的 callback 接口回调方法。这样，Runtime 和 Stub 都有对方调用的方法，一个应用的请求通过 Runtime 调用 Stub 的 operations 方法，而 Stub 响应 operations 方法并完成后，再调用 Runtime 的 callback 方法进行返回。如下图，以 Led 为例的示意图：
Led App 为 Android 应用程序，Led App 里的 Java 代码不能操作硬件，将硬件操作工作交给本地 module 库 led_runtime.so，它从当前系统中查找 Led Stub，查找到之后，Led Stub 将硬件驱动操作返回给 module，Led App 操作硬件时，通过保存在 module 中的操作接口间接访问底层硬件。
3、Module 架构与 Stub 构架对比
在 Module 架构中，本地代码由 so 库实现，上层直接将 so 库映射进进程空间，会有代码重入及设备多次打开的问题。新的 Stub 框架虽然也要加载 module 库，但是这个 module 已经不包含操作底层硬件驱动的功能了，它里面保存的只是底层 Stub 提供的操作接口，底层 Stub 扮演了“接口提供者”的角色。当 Stub 第一次被使用时加载到内存，后续再使用时仅返回硬件对象操作接口，不会存在设备多次打开问题，并且由于多进程访问时返回的只是函数指针，代码没有重入问题。
4、应用调用 HAL 层的完整过程
Android 的 HAL 的实现需要通过 JNI(Java Native Interface)，JNI 简单来说就是 java 程序可以调用 C/C++ 写的动态链接库，这样的话，HAL 可以使用 C/C++ 语言编写，效率更高。Android APP 可以直接调用 .so（上面第一种 Module 架构方法），也可以通过app->app_manager->service(java)->service(jni)->HAL来调用（上面第二种 Stub 架构方法）。
第二种方法的基本框架如下所示：
继续以 LED 的调用过程为例：
描述下调用过程，如下：
- JNI -> 通用硬件模块 -> 硬件模块 -> 内核驱动接口；
- 具体一点：
JNI->libhardware.so->xxx.xxx.so->kernel； - 再具体来说：android frameworks 中 JNI 调用 hardware.c 中定义的
hw_get_module函数来获取硬件模块，然后调用硬件模块中的方法，硬件模块中的方法直接调用内核接口完成相关功能（看不懂没关系，下文会具体解释）。
HAL的结构体
一般来说 HAL moudle 需要涉及的是三个关键结构体：
struct hw_module_t; //抽象硬件模块结构体
struct hw_module_methods_t; //硬件模块方法结构体
struct hw_device_t; //抽象硬件设备结构体
这三个结构体定义在 hardware.h 中，具体的代码路径：
如下图所示：
其中头文件 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
uint32_t tag;
uint16_t version_major;
uint16_t version_minor;
cost char* id;
const char* author;
struct hw_module_methods_t* methods;
void* dso;
uint32_t reserved[10];
hw_module_t;
/**
* Create a function list
*/
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;
/**
* 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;
uint32_t version;
struct hw_module_t* module;
uint32_t reserved[12];
int (*close)(struct hw_device_t* device)
hw_device_t;
以上关于 HAL 模块的关键变量和结构体，概述如下：
Android HAL 将各类硬件设备抽象为硬件模块，HAL 使用hw_module_t结构体描述一类硬件抽象模块。每个硬件抽象模块都对应一个动态链接库，一般是由厂商提供的，这个动态链接库必须尊重 HAL 的命名规范才能被 HAL 加载到，我们后面会看到。每一类硬件抽象模块又包含多个独立的硬件设备，HAL 使用hw_device_t结构体描述硬件模块中的独立硬件设备。下面来分析下 HAL moudle 的三个结构体。
1、先看看头文件中定义的通用硬件模块结构体hw_module_t，它声明了 JNI 调用的接口函数hw_get_module。具体定义如下：
/**
* 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;
/** 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;
/** 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;
如注释所说，所有的 HAL 模块都要有一个以HAL_MODULE_INFO_SYM命名的结构，而且这个结构要以hw_module_t为第一个成员（这里可以理解为是一种继承关系，相当于硬件模块的HAL_MODULE_INFO_SYM结构体，继承了hw_module_t，只不过是 C 语言中没有继承的概念，是通过在结构体中包含的方式间接实现的）。咱们以 lights，sensor 为例：
struct sensors_module_t
struct hw_module_t common;
int (*get_sensors_list)(struct sensors_module_t* module,
struct sensor_t const** list);
;
/*
* The lights Module
*/
struct light_module_t HAL_MODULE_INFO_SYM =
.common:
tag: HARDWARE_MODULE_TAG,
version_major: 1,
version_minor: 0,
id: LIGHTS_HARDWARE_MODULE_ID,
name: "Lights module",
author: "Rockchip",
methods: &light_module_methods,
;
const struct sensors_module_t HAL_MODULE_INFO_SYM =
.common =
.tag = HARDWARE_MODULE_TAG,
.version_major = 1,
.version_minor = 0,
.id = SENSORS_HARDWARE_MODULE_ID,
.name = "Stingray SENSORS Module",
.author = "Motorola",
.methods = &sensors_module_methods,
,
.get_sensors_list = sensors__get_sensors_list
;
2、在 hw_module_t中比较重要的是硬件模块方法结构体hw_module_methods_t的定义如下：
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;
该方法只有一个函数指针 open，该方法在定义HAL_MODULE_INFO_SYM的时候被初始化。根据参数可以推断出 open 是用来打开硬件模块获取模块中的硬件设备。由于一个硬件抽象模块中可能包含多个设备，因此需要根据传入的设备id来获取相应的硬件设备hw_device_t。所以这里的 device 就表示一个已经打开的硬件设备。
3、hw_module_methods_t中调用的设备结构体参数 hw_device_t ，前面提到 HAL 使用hw_device_t结构体描述硬件模块中的独立硬件设备，其定义如下：
/**
* 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 number for hw_device_t */
uint32_t version;
/** reference to the module this device belongs to */
struct hw_module_t* module;
/** padding reserved for future use */
uint32_t reserved[12];
/** Close this device */
int (*close)(struct hw_device_t* device);
hw_device_t;
HAL 规定每个硬件设备都必须定义一个硬件设备描述结构体，该结构体必须以hw_device_t作为第一个成员变量，后跟设备相关的公开函数和属性。
- tag：初始化为常量 HARDWARE_DEVICE_TAG;
- module：表示该硬件设备归属于哪一个硬件抽象模块;
- close：函数指针，用来关闭硬件设备。
同样来看下实际的例子：
struct light_device_t
struct hw_device_t common;
int (*set_light)(struct light_device_t* dev,
struct light_state_t const* state);
;
/**
* Every device data structure must begin with hw_device_t
* followed by module specific public methods and attributes.
*/
struct sensors_poll_device_t
struct hw_device_t common;
int (*activate)(struct sensors_poll_device_t *dev,
int handle, int enabled);
int (*setDelay)(struct sensors_poll_device_t *dev,
int handle, int64_t ns);
int (*poll)(struct sensors_poll_device_t *dev,
sensors_event_t* data, int count);
;
到此，HAL 的 3 个核心数据结构体就分析完了。硬件厂商必须遵循HAL规范和命名，实现抽象硬件模块结构体 hw_module_t 和抽象硬件设备结构体hw_device_t，并且在硬件模块方法结构体hw_module_methods_t中提供 open 函数来获取 hw_device_t。下面我们来看看 HAL 到底是怎样获取硬件模块和硬件设备的，以及是如何加载和解析对应的动态共享库的。
模块实现方法
在 Android 的 HAL 框架使用通用的 “321架构”，也就是三个结构体，两个常量，一个函数。所有的硬件抽象模块都遵循321架构，在此基础上扩展自有的功能。三个结构体上面已经分析完了，接着来看下两个常量（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"
最后看下“一个函数”：在 hardware.c 文件中有一个关键的公共 API——hw_get_module，其作用是根据 module_id 去查找注册相对应的硬件对象，然后载入相应的HAL层驱动模块的 so 文件：
先给个图总结下 hardware.c 文件中定义的 HAL 整体的获取 Module 和 Device 结构对象的流程：
下面以 lights 模块为例进行分析，其源文件位置：(Android 5.1 源码)：
/frameworks/base/services/core/java/com/android/server/lights/
/frameworks/base/services/core/jni/com_android_server_lights_LightsService.cpp
/hardware/libhardware/include/hardware/lights.h
访问设备大概流程：
app--->frameworks--->hardware--->kernel驱动
（1）frameworks 通过 jni 调用hw_get_module()获得 HAL 对应的模块，在 lights.h中定义有 lights 模块的ID：
#define LIGHTS_HARDWARE_MODULE_ID "lights"
（2）在 Android 5.1 版本的源码frameworks/base/services/core/jni/com_android_server_LightsService.cpp的i nit_native 方法中调用hw_ge_module()，代码如下：
static jint init_native(JNIEnv *env, jobject clazz)
int err;
hw_module_t* module;
Devices* devices;
devices = (Devices*)malloc(sizeof(Devices));
err = hw_get_module(LIGHTS_HARDWARE_MODULE_ID, (hw_module_t const**)&module);
if (err == 0)
devices->lights[LIGHT_INDEX_BACKLIGHT]
= get_device(module, LIGHT_ID_BACKLIGHT);
//………………………………………….
（3）由上已知hw_get_module函数在 hardware.c 中实现：
int hw_get_module(const char *id, const struct hw_module_t **module)
return hw_get_module_by_class(id, NULL, module);
（4）来看看hw_get_module_by_class是如何实现的：
/** Base path of the hal modules */
#define HAL_LIBRARY_PATH1 "/system/lib/hw"
#define HAL_LIBRARY_PATH2 "/vendor/lib/hw"
/**
* 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]));
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); //执行加载和解析共享库的工作
可以看到，在hw_get_module_by_class函数中：
- 首先根据 class_id 生成 module name，这里就是
hw_get_module函数传进来的 id； - 再通过 property_get 获得 varient_key 中定义的系统属性，如果系统中有定义该属性，就会获得一个模块名.属性名组成的一个 so 的名称；
- 然后去
/system/lib/hw、/vendor/lib/hw下查看，该 so 是否存在，如果存在，调用 load 函数，打开.so文件； - 如果不存在，则遍历 variant_keys 数组中定义的属性名称来获取属性值，得到目标模块库名字，检查其是否存在；
- 如果根据属性值都没有找到模块共享库，则尝试检查 default 的库是否存在，如果仍然不存在，返回错误；
- 如果上述任何一次尝试找到了目标共享库，path 就是目标共享库的文件路径，调用 load 执行真正的加载库的工作。
（5）再看 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 Android硬件抽象层(HAL)深入剖析