HAL/JNI简明笔记（一）——HAL基本框架

原文博客地址：http://blog.csdn.net/sgmenghuo/article/details/44563765

环境：

android 4.3

HAL(hardware abstract layer)是位于操作系统与硬件之间的接口层，目的在于硬件抽象化。它存在于linux的应用层，它在Android系统中的位置是：向下连接驱动，向上给JNI提供接口。

源码的位置：

msm8x12\hardware\libhardware_legacy 为过去的HAL目录，采用链接库模块概念的旧架构，audio,power,wifi,vibrator,uevent等有使用该架构

X:\D500_android\msm8x12\hardware\libhardware 为当前使用的HAL架构，audio,bluetooth,camera,fb,gps,lights,power,sensor,rtc,nfc等有使用该架构

两种HAL架构示意图如下：

其中左边的HAL架构继承的是老的linux共享库思路，把硬件接口都打包到libhardware_legacy.so，Android的JNI在要调用到这个库的硬件接口函数时，只要将Android.mk中的LOCAL_SHARED_LIBRARIES增加libhardware_legacy就行，这样就会到共享库中获取接口。

缺点：多个进程使用时，会映射到多个进程空间，造成浪费。

右边的HAL架构是当前Android源码中使用的思路，每一个硬件模块称为一个stub（代理人），并且借尸so的形式编译，所有的stub都要通过libhardware.so(由hardware.c)才能找到每一个stub，才能回调每一个stub中硬件抽象接口，当然stub在编写时需要按照HAL_MODULE_INFO_SYM的格式来写，通过libhardware.so找到stub时，就会将该stub加载到内存，返回该stub的模块指针。

优点：采用HAL module和HAL stub结合形式，HAL stub不是共享库，上层只拥有访问stub的函数指针，并不需要stub，Runtime只需要根据module ID并通过HAL module提供的统一接口就能取得stub的操作函数，只会被映射到一个进程，不会浪费空间。

对于libhardware.so/hardware.c而言，我们只需关心它里面几个重要的结构体和一些路径和命名规则即可。

比较重要的结构体代码片如下：

[cpp] view plain copy

print ?

1. / 
2.   Every device data structure must begin with hw_device_t 
3.   followed by module specific public methods and attributes. 
4.   每个设备结构体成员都要以hw_device_t开头，然后再是设备专有其他属性方法 
5.  /  
6. typedef struct hw_device_t {  
7.     / tag must be initialized to HARDWARE_DEVICE_TAG /  
8.     uint32_t tag;  
9.   
10.     uint32_t version;  
11.   
12.     / reference to the module this device belongs to /  
13.     struct hw_module_t* module;  
14.   
15.     / padding reserved for future use /  
16.     uint32_t reserved[12];  
17.   
18.     / Close this device ,一般是回收device结构体/  
19.     int (close)(struct hw_device_t device);  
20.   
21. } hw_device_t;  
22.   
23. / 
24.   每个模块stub结构体变量必须命名为HAL_MODULE_INFO_SYM，数据域成员必须以 
25.   hw_module_t开头，然后再是模块专有属性方法 
26.  /  
27. typedef struct hw_module_t {  
28.     / tag must be initialized to HARDWARE_MODULE_TAG /  
29.     uint32_t tag;  
30.   
31.     uint16_t module_api_version;  
32. #define version_major module_api_version  
33.     / 
34.       Presently, 0 is the only valid value. 
35.       当前必须赋值为0 
36.      /  
37.     uint16_t hal_api_version;  
38. #define version_minor hal_api_version  
39.   
40.     / 模块的module ID /  
41.     const char id;  
42.   
43.     / Name of this module /  
44.     const char name;  
45.   
46.     / Author/owner/implementor of the module /  
47.     const char author;  
48.   
49.     / Modules methods /  
50.     struct hw_module_methods_t* methods;  
51.   
52.     / module’s dso /  
53.     void dso;  
54.   
55.     / padding to 128 bytes, reserved for future use /  
56.     uint32_t reserved[32-7];  
57.   
58. } hw_module_t;  
59.   
60.   
61. typedef struct hw_module_methods_t {  
62.     / Open a specific device ，基本就是malloc设备结构体，并加上回调函数接口/  
63.     int (open)(const struct hw_module_t module, const char id,  
64.             struct hw_device_t device);  
65.   
66. } hw_module_methods_t;  

/* 

 * Every device data structure must begin with hw_device_t 

 * followed by module specific public methods and attributes. 

 * 每个设备结构体成员都要以hw_device_t开头，然后再是设备专有其他属性方法 

 */ 

typedef struct hw_device_t { 

    /* tag must be initialized to HARDWARE_DEVICE_TAG / 

    uint32_t tag;

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 ,一般是回收device结构体*/
int (*close)(struct hw_device_t* device);

} hw_device_t;

/**
* 每个模块stub结构体变量必须命名为HAL_MODULE_INFO_SYM，数据域成员必须以
* hw_module_t开头，然后再是模块专有属性方法
*/
typedef struct hw_module_t {
/* tag must be initialized to HARDWARE_MODULE_TAG /
uint32_t tag;

uint16_t module_api_version;

#define version_major module_api_version /** * Presently, 0 is the only valid value. * 当前必须赋值为0 */ uint16_t hal_api_version; #define version_minor hal_api_version /** 模块的module ID */ 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; typedef struct hw_module_methods_t { /** Open a specific device ，基本就是malloc设备结构体，并加上回调函数接口*/ int (*open)(const struct hw_module_t* module, const char* id, struct hw_device_t** device); } hw_module_methods_t;

下面以名为ctp的 HAL stub为例，给出结构图来解释这些结构体之间的关系：

另外libhardware.so搜索stub的路径优先顺序为：先搜索/vendor/lib/hw目录，再搜索/system/lib/hw；

在每个路径下搜索stub的命名优先顺序为(其中name为定义的module ID，后一个参数为属性值):

<MODULE_ID>.$(ro.product.board).so例如led.trout.so

<MODULE_ID>.$(ro.board.platform).so例如led.msm7k.so

<MODULE_ID>.$(ro.arch).so例如led.ARMV6.so

若以上都未搜索到stub，那么就搜索/system/lib/hw/<MODULE_ID>.default.so

新框架总的思路：

具体来说：android frameworks中JNI调用/hardware/libhardware/hardware.c中定义的hw_get_module函数来获取硬件模块，然后调用硬件模块中的方法，硬件模块中的方法直接调用内核接口完成相关功能。

其中每一个module/stub的定义时都叫做HAL_MODULE_INFO_SYM，那么当系统中存在两个或者更多个使用了相同HAL Module Name的so的时候，不就混乱了么？

带着这个疑问查看 Android 源码，会发现 Android 中实现调用 HAL 是通过 hw_get_module 实现的。

int hw_get_module(const char *id, const struct hw_module_t **module);

这是其函数原型， id 会指定 Hardware 的 id ，这是一个字符串，比如 sensor 的 id 是

#define SENSORS_HARDWARE_MODULE_ID “sensors” ，如果找到了对应的 hw_module_t 结构体，会将其指针放入 *module 中。看看它的实现。。。。

/* Loop through the configuration variants looking for a module */     for (i=0 ; i<HAL_VARIANT_KEYS_COUNT+1 ; i++) {         if (i < HAL_VARIANT_KEYS_COUNT) {              // 获取 ro.hardware/ro.product.board/ro.board.platform/ro.arch 等 key 的值。             if (property_get(variant_keys[i], prop, NULL) == 0) {                 continue;             }             snprintf(path, sizeof(path), “%s/%s.%s.so”,                     HAL_LIBRARY_PATH, id, prop);               // 如果开发板叫做 mmdroid, 那么这里的 path 就是system/lib/hw/sensor.mmdroid.so         } else {             snprintf(path, sizeof(path), “%s/%s.default.so”,                     HAL_LIBRARY_PATH, id);// 默认会加载 /system/lib/hw/sensor.default.so            }         if (access(path, R_OK)) {             continue;         }         /* we found a library matching this id/variant */         break;     }

status = -ENOENT;     if (i < HAL_VARIANT_KEYS_COUNT+1) {         /* load the module, if this fails, we’re doomed, and we should not try          * to load a different variant. */         status = load(id, path, module);// 调用 load 函数打开动态链接库     }

获取了动态链接库的路径之后，就会调用 load 函数打开它，下面会打开它。

 

奥秘在 load 中

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();         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 ”     hmi = (struct hw_module_t *)dlsym(handle, sym);// 查找“ HMI ”这个导出符号，并获取其地址     if (hmi == NULL) {         LOGE(“load: couldn’t find symbol %s”, sym);         status = -EINVAL;         goto done;     }   /* Check that the id matches */ // 找到了 hw_module_t 结构！！！     if (strcmp(id, hmi->id) != 0) {         LOGE(“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 {         LOGV(“loaded HAL id=%s path=%s hmi=%p handle=%p”,                 id, path, *pHmi, handle);     }   // 凯旋而归     *pHmi = hmi;        return status; }

从上面的代码中，会发现一个很奇怪的宏 HAL_MODULE_INFO_SYM_AS_STR ，它直接被定义为了 #define HAL_MODULE_INFO_SYM_AS_STR  “HMI” ，为何根据它就能从动态链接库中找到这个 hw_module_t 结构体呢？我们查看一下我们用到的 hal 对应的 so 就可以了，在 linux 中可以使用 readelf XX.so –s 查看。

Symbol table ‘.dynsym’ contains 28 entries:    Num:     Value  Size Type    Bind   Vis      Ndx Name      0: 00000000     0 NOTYPE  LOCAL  DEFAULT  UND      1: 00000594     0 SECTION LOCAL  DEFAULT    7      2: 00001104     0 SECTION LOCAL  DEFAULT   13      3: 00000000     0 FUNC    GLOBAL DEFAULT  UND ioctl      4: 00000000     0 FUNC    GLOBAL DEFAULT  UND strerror      5: 00000b84     0 NOTYPE  GLOBAL DEFAULT  ABS __exidx_end      6: 00000000     0 OBJECT  GLOBAL DEFAULT  UND __stack_chk_guard      7: 00000000     0 FUNC    GLOBAL DEFAULT  UND __aeabi_unwind_cpp_pr0      8: 00000000     0 FUNC    GLOBAL DEFAULT  UND __errno      9: 00001188     0 NOTYPE  GLOBAL DEFAULT  ABS _bss_end__     10: 00000000     0 FUNC    GLOBAL DEFAULT  UND malloc     11: 00001188     0 NOTYPE  GLOBAL DEFAULT  ABS __bss_start__     12: 00000000     0 FUNC    GLOBAL DEFAULT  UND __android_log_print     13: 00000b3a     0 NOTYPE  GLOBAL DEFAULT  ABS __exidx_start     14: 00000000     0 FUNC    GLOBAL DEFAULT  UND __stack_chk_fail     15: 00001188     0 NOTYPE  GLOBAL DEFAULT  ABS __bss_end__     16: 00001188     0 NOTYPE  GLOBAL DEFAULT  ABS __bss_start     17: 00000000     0 FUNC    GLOBAL DEFAULT  UND memset     18: 00000000     0 FUNC    GLOBAL DEFAULT  UND __aeabi_uidiv     19: 00001188     0 NOTYPE  GLOBAL DEFAULT  ABS __end__     20: 00001188     0 NOTYPE  GLOBAL DEFAULT  ABS _edata     21: 00001188     0 NOTYPE  GLOBAL DEFAULT  ABS _end     22: 00000000     0 FUNC    GLOBAL DEFAULT  UND open     23: 00080000     0 NOTYPE  GLOBAL DEFAULT  ABS _stack     24: 00001104   128 OBJECT  GLOBAL DEFAULT   13 HMI     25: 00001104     0 NOTYPE  GLOBAL DEFAULT   13 __data_start     26: 00000000     0 FUNC    GLOBAL DEFAULT  UND close     27: 00000000     0 FUNC    GLOBAL DEFAULT  UND free

从上面中，第 24 个符号，名字就是“ HMI ”，对应于 hw_module_t 结构体。再去对照一下 HAL 的代码。

/*   * The COPYBIT Module   */ struct copybit_module_t HAL_MODULE_INFO_SYM = {     common: {         tag: HARDWARE_MODULE_TAG,         version_major: 1,         version_minor: 0,         id: COPYBIT_HARDWARE_MODULE_ID,         name: “QCT MSM7K COPYBIT Module”,         author: “Google, Inc.”,         methods: &copybit_module_methods     } };

这里定义了一个名为 HAL_MODULE_INFO_SYM 的 copybit_module_t 的结构体， common 成员为hw_module_t 类型。注意这里的 HAL_MODULE_INFO_SYM 变量必须为这个名字，这样编译器才会将这个结构体的导出符号变为“ HMI ”，这样这个结构体才能被 dlsym 函数找到！

综上，我们知道了 andriod HAL 模块也有一个通用的入口地址，这个入口地址就是 HAL_MODULE_INFO_SYM变量，通过它，我们可以访问到 HAL 模块中的所有想要外部访问到的方法。

ref：Jerry_xianrui    Android HAL(硬件抽象层)介绍以及调用

                </div>