一 什么是HAL
HAL 可定义一个标准接口以供硬件供应商实现,这可让 Android 忽略较低级别的驱动程序实现。借助 HAL,您可以顺利实现相关功能,而不会影响或更改更高级别的系统。HAL 实现会被封装成模块,并由 Android 系统适时地加载。
硬件抽象层是介于android内核kernel和上层之间的抽象出来的一层结构。他是对linux驱动的一个封装,对上层提供统一接口,上层应用不必知道下层硬件具体怎么实现工作的,它屏蔽了底层的实现细节。
您必须为您的产品所提供的特定硬件实现相应的 HAL(和驱动程序)。HAL 实现通常会内置在共享库模块(.so
文件)中,但 Android 并不要求 HAL 实现与设备驱动程序之间进行标准交互,因此您可以视情况采取适当的做法。不过,要使 Android 系统能够与您的硬件正确互动,您必须遵守各个特定于硬件的 HAL 接口中定义的合同。
为了保证 HAL 具有可预测的结构,每个特定于硬件的 HAL 接口都要具有 hardware/libhardware/include/hardware/hardware.h
中定义的属性。这类接口可让 Android 系统以一致的方式加载 HAL 模块的正确版本。HAL 接口包含两个组件:模块和设备。
1.1 HAL 模块
模块表示被封装且存储为共享库 (.so file
) 的 HAL 实现。hardware/libhardware/include/hardware/hardware.h
标头文件会定义一个表示模块的结构体 (hw_module_t
),其中包含模块的版本、名称和作者等元数据。Android 会根据这些元数据来找到并正确加载 HAL 模块。
/**
* 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[-]; } hw_module_t;
另外,hw_module_t
结构体还包含指向另一个结构体 hw_module_methods_t
的指针,后面这个结构体会包含一个指向相应模块的 open 函数的指针。此 open 函数用于与相关硬件(此 HAL 是其抽象形式)建立通信。
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_device_t,这个结构体主要是用来描述模块中硬件设备的属性信息什么的。一个硬件模块可能有多个硬件设备。
比如说,传感器模块,sensor_module,是一个硬件模块,但是手机中的传感器就对应的有好多种,比如加速度acc_sensor,磁传感器M_sensor等,那么他们都属于sensor_module,但是他们有都有自己的hw_device_t结构体来描述。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; //设备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[];//保留 /** Close this device */
int (*close)(struct hw_device_t* device);//关闭设备的函数指针 } hw_device_t;
第三个成员module指向的是这个设备归属的硬件模块结构体。
每个特定于硬件的 HAL 通常都会使用附加信息为该特定硬件扩展通用的 hw_module_t
结构体。例如,在相机 HAL 中,camera_module_t
结构体会包含一个 hw_module_t
结构体以及其他特定于相机的函数指针:
typedef struct camera_module {
hw_module_t common;
int (*get_number_of_cameras)(void);
int (*get_camera_info)(int camera_id, struct camera_info *info);
} camera_module_t;
实现 HAL 并创建模块结构体时,您必须将其命名为 HAL_MODULE_INFO_SYM
。以下是 Nexus 9 音频 HAL 的示例:
struct audio_module HAL_MODULE_INFO_SYM = {
.common = {
.tag = HARDWARE_MODULE_TAG,
.module_api_version = AUDIO_MODULE_API_VERSION_0_1,
.hal_api_version = HARDWARE_HAL_API_VERSION,
.id = AUDIO_HARDWARE_MODULE_ID,
.name = "NVIDIA Tegra Audio HAL",
.author = "The Android Open Source Project",
.methods = &hal_module_methods,
},
};
1.2 HAL 设备
设备是产品硬件的抽象表示。例如,一个音频模块可能包含主音频设备、USB 音频设备或蓝牙 A2DP 音频设备。
设备由 hw_device_t
结构体表示。与模块类似,每类设备都定义了一个通用 hw_device_t
的详细版本,其中包含指向硬件特定功能的函数指针。例如,audio_hw_device_t
结构体类型会包含指向音频设备操作的函数指针:
struct audio_hw_device {
struct hw_device_t common; /**
* used by audio flinger to enumerate what devices are supported by
* each audio_hw_device implementation.
*
* Return value is a bitmask of 1 or more values of audio_devices_t
*/
uint32_t (*get_supported_devices)(const struct audio_hw_device *dev);
...
};
typedef struct audio_hw_device audio_hw_device_t;
除了这些标准属性之外,每个特定于硬件的 HAL 接口都可以定义更多的自有功能和要求。有关详情,请参阅 HAL 参考文档以及各 HAL 的单独说明。
1.3 编译 HAL 模块
HAL 实现会内置在模块 (.so
) 文件中,并由 Android 适时地动态链接。您可以为每个 HAL 实现创建 Android.mk
文件并指向源文件,从而编译模块。一般来说,您的共享库必须以特定格式命名,以方便找到并正确加载。各模块的命名方案略有不同,但它们都遵循以下通用模式:<module_type>.<device_name>
。
1.4 HAL 类型
为了更好地实现模块化,Android 8.0 对 Android 操作系统底层进行了重新架构。作为此变化的一部分,运行 Android 8.0 的设备必须支持绑定式或直通式 HAL:
- 绑定式 HAL。以 HAL 接口定义语言 (HIDL) 表示的 HAL。这些 HAL 取代了早期 Android 版本中使用的传统 HAL 和旧版 HAL。在绑定式 HAL 中,Android 框架和 HAL 之间通过 Binder 进程间通信 (IPC) 调用进行通信。所有在推出时即搭载了 Android 8.0 或后续版本的设备都必须只支持绑定式 HAL。
- 直通式 HAL。以 HIDL 封装的传统 HAL 或旧版 HAL。这些 HAL 封装了现有的 HAL,可在绑定模式和 Same-Process(直通)模式下使用。升级到 Android 8.0 的设备可以使用直通式 HAL。
1.4.1 HAL 模式要求
设备 | 直通式 | 绑定式 |
---|---|---|
搭载 Android 8.0 的设备 | 直通式 HAL 中列出的 HAL 必须为直通式。 | 所有其他 HAL 均为绑定式(包括作为供应商扩展程序的 HAL)。 |
升级到 Android 8.0 的设备 | 直通式 HAL 中列出的 HAL 必须为直通式。 | 绑定式 HAL 中列出的 HAL 必须为绑定式。 |
供应商映像提供的所有其他 HAL 既可以在直通模式下使用,也可以在绑定模式下使用。 |
1.4.2 绑定式 HAL
Android 要求所有 Android 设备(无论是搭载 Android O 的设备还是升级到 Android O 的设备)上的下列 HAL 均为绑定式:
-
android.hardware.biometrics.fingerprint@2.1
。取代 Android 8.0 中已不存在的fingerprintd
。 -
android.hardware.configstore@1.0
。Android 8.0 中的新 HAL。 -
android.hardware.dumpstate@1.0
。此 HAL 提供的原始接口可能无法继续使用,并且已更改。因此,dumpstate_board
必须在指定的设备上重新实现(这是一个可选的 HAL)。 -
android.hardware.graphics.allocator@2.0
。在 Android 8.0 中,此 HAL 必须为绑定式,因此无需在可信进程和不可信进程之间分享文件描述符。 -
android.hardware.radio@1.0
。取代由存活于自身进程中的rild
提供的接口。 -
android.hardware.usb@1.0
。Android 8.0 中的新 HAL。 -
android.hardware.wifi@1.0
。Android 8.0 中的新 HAL,可取代此前加载到system_server
的旧版 WLAN HAL 库。 -
android.hardware.wifi.supplicant@1.0
。在现有wpa_supplicant
进程之上的 HIDL 接口
注意:Android 提供的以下 HIDL 接口将一律在绑定模式下使用:android.frameworks.*
、android.system.*
和 android.hidl.*
(不包括下文所述的 android.hidl.memory@1.0
)。
1.4.3 直通式 HAL
Android 要求所有 Android 设备(无论是搭载 Android O 的设备还是升级到 Android O 的设备)上的下列 HAL 均在直通模式下使用:
-
android.hardware.graphics.mapper@1.0
。将内存映射到其所属的进程中。 -
android.hardware.renderscript@1.0
。在同一进程中传递项(等同于openGL
)。
上方未列出的所有 HAL 在搭载 Android O 的设备上都必须为绑定式。
Same-Process HAL
Same-Process HAL (SP-HAL) 一律在使用它们的进程中打开,其中包括未以 HIDL 表示的所有 HAL,以及那些非绑定式的 HAL。SP-HAL 集的成员只能由 Google 控制,这一点没有例外。
SP-HAL 包括以下 HAL:
openGL
Vulkan
-
android.hidl.memory@1.0
(由 Android 系统提供,一律为直通式) -
android.hardware.graphics.mapper@1.0
。 android.hardware.renderscript@1.0
1.5 传统 HAL 和旧版 HAL
传统 HAL(在 Android 8.0 中已弃用)是指与具有特定名称及版本号的应用二进制接口 (ABI) 标准相符的接口。大部分 Android 系统接口(相机、音频和传感器等)都采用传统 HAL 形式(已在 hardware/libhardware/include/hardware 下进行定义)。
旧版 HAL(也已在 Android 8.0 中弃用)是指早于传统 HAL 的接口。一些重要的子系统(WLAN、无线接口层和蓝牙)采用的就是旧版 HAL。虽然没有统一或标准化的方式来指明是否为旧版 HAL,但如果 HAL 早于 Android 8.0 而出现,那么这种 HAL 如果不是传统 HAL,就是旧版 HAL。有些旧版 HAL 的一部分包含在 libhardware_legacy 中,而其他部分则分散在整个代码库中。
二、操作硬件
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中,打开这个文件可以看到定义如下:
/*
* Copyright (C) 2008 The Android Open Source Project
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/ #include <hardware/hardware.h> #include <cutils/properties.h> #include <dlfcn.h>
#include <string.h>
#include <pthread.h>
#include <errno.h>
#include <limits.h> #define LOG_TAG "HAL"
#include <utils/Log.h> /** 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 "<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[])); /**
* 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
*/
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) != ) {
ALOGE("load: id=%s != hmi->id=%s", id, hmi->id);
status = -EINVAL;
goto done;
} hmi->dso = handle; /* success */
status = ; done:
if (status != ) {
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) == )
return ; snprintf(path, path_len, "%s/%s.%s.so",
HAL_LIBRARY_PATH1, name, subname);
if (access(path, R_OK) == )
return ; 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) > ) {
if (hw_module_exists(path, sizeof(path), name, prop) == ) {
goto found;
}
} /* Loop through the configuration variants looking for a module */
for (i= ; i<HAL_VARIANT_KEYS_COUNT; i++) {
if (property_get(variant_keys[i], prop, NULL) == ) {
continue;
}
if (hw_module_exists(path, sizeof(path), name, prop) == ) {
goto found;
}
} /* Nothing found, try the default */
if (hw_module_exists(path, sizeof(path), name, "default") == ) {
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);
}
在dlopen的()函数以指定模式打开指定的动态连接库文件,并返回一个句柄给调用进程。使用dlclose()来卸载打开的库。
hw_get_module
int hw_get_module(const char *id, const struct hw_module_t **module)
{
int status;
int i;
const struct hw_module_t *hmi = NULL;
char prop[PATH_MAX];
char path[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.
*/ /* Loop through the configuration variants looking for a module */
for (i= ; i<HAL_VARIANT_KEYS_COUNT+ ; i++) {
if (i < HAL_VARIANT_KEYS_COUNT) {
if (property_get(variant_keys[i], prop, NULL) == ) {//获取属性
continue;
}
snprintf(path, sizeof(path), "%s/%s.%s.so",
HAL_LIBRARY_PATH1, id, prop);
if (access(path, R_OK) == ) break;//检查system路径是否有库文件 snprintf(path, sizeof(path), "%s/%s.%s.so",
HAL_LIBRARY_PATH2, id, prop);
if (access(path, R_OK) == ) break;//检查vender路径是否有库文件
} else {
snprintf(path, sizeof(path), "%s/%s.default.so",//如果都没有,则使用缺省的
HAL_LIBRARY_PATH1, id);
if (access(path, R_OK) == ) break;
}
} status = -ENOENT;
if (i < HAL_VARIANT_KEYS_COUNT+) {
/* load the module, if this fails, we're doomed, and we should not try
* to load a different variant. */
status = load(id, path, module);//装载库,得到module
} return status;
}
snprintf(),函数原型为int snprintf(char *str, size_t size, const char *format, ...)。将可变参数 “…” 按照format的格式格式化为字符串,然后再将其拷贝至str中。
access(filename, 0) 表示判断文件是否存在 access 返回值是0的时候,表示存在,而返回-1的时候,表示失败。
property_set/property_get位于libcutils.so库。任何进程若要调用这两个函数,需要链接libcutils.so(https://blog.csdn.net/decisiveness/article/details/49852295)。
看第一行我们知道有两个参数,第一参数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]));
原来它是ariant_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)函数获取到的,其实这个函数是通过ariant_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。
三 如何实现加载共享库
以下为load函数定义,同样在/hardware/libhardware/hardware.c中实现的。
/**
* 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)
{//传入硬件模块id和库所在路径,获取到硬件模块结构体
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();
LOGE("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) {
LOGE("load: couldn't find symbol %s", sym);
status = -EINVAL;
goto done;
} /* Check that the id matches */
if (strcmp(id, hmi->id) != ) {//匹配解析出硬件模块的id和传入我们实际想要得到的模块id是否一致
LOGE("load: id=%s != hmi->id=%s", id, hmi->id);
status = -EINVAL;
goto done;
} hmi->dso = handle; //将打开库得到句柄传给硬件模块的dso /* success */
status = ; done:
if (status != ) {
hmi = NULL;
if (handle != NULL) {
dlclose(handle);
handle = NULL;
}
} else {
LOGV("loaded HAL id=%s path=%s hmi=%p handle=%p",
id, path, *pHmi, handle);
} *pHmi = hmi;//将得到的module的结果通过第三个参数传给hw_module_t return status;
}
Linux提供了一套API来动态装载库。下面列出了这些API:
- dlopen,打开一个库,并为使用该库做些准备。
- dlsym,在打开的库中查找符号的值。
- dlclose,关闭库。
- dlerror,返回一个描述最后一次调用dlopen、dlsym,或dlclose的错误信息的字符串。
C语言用户需要包含头文件dlfcn.h才能使用上述API。glibc还增加了两个POSIX标准中没有的API:
- dladdr,从函数指针解析符号名称和所在的文件。
- dlvsym,与dlsym类似,只是多了一个版本字符串参数。
可以看到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就能打开硬件模块对应的设备了,通过结构体中的一些方法就能操作硬件设备了。
四 实践
见番外篇
参考:
https://www.cnblogs.com/y041039/archive/2013/05/22/3092774.html
https://www.cnblogs.com/y041039/archive/2013/05/22/3092868.html
https://www.cnblogs.com/y041039/archive/2013/05/23/3094579.html
https://www.cnblogs.com/y041039/archive/2013/05/23/3094928.html
https://www.cnblogs.com/y041039/archive/2013/05/23/3095621.html
https://www.linuxidc.com/Linux/2011-07/38983.htm
进一步了解 Linux内核 -> HAL -> JNI -> framework -> app:
别人的实例
Android硬件抽象层(HAL)概要介绍和学习计划
Android之 看“马达”如何贯通Android系统 (从硬件设计 --> 驱动 --> HAL --> JNI --> Framework --> Application)