Android--hw_get_module解析
2014-03-27 15:08
274 查看
我们知道，google为了保护硬件厂商的信息，在Android中添加了一层，也就是大名鼎鼎的HAL层。
在看HAL的编写方法的过程中，会发现整个模块貌似没有一个入口。一般说来模块都要有个入口，比
如应用程序有main函数，可以为加载器进行加载执行，dll文件有dllmain，而对于我们自己写的动态
链接库，我们可以对库中导出的任何符号进行调用。
问题来了，Android中的HAL是比较具有通用性的，需要上层的函数对其进行加载调用，Android的
HAL加载器是如何实现对不同的Hardware Module进行通用性的调用的呢？
带着这个疑问查看Android源码，会发现Android中实现调用HAL是通过hw_get_module实现的。
[cpp] view
plaincopy
int hw_get_module(const char *id, const struct hw_module_t **module);
这是其函数原型，id会指定Hardware的id，这是一个字符串，比如我们比较熟悉的led的id是
#define SENSORS_HARDWARE_MODULE_ID “led”，如果找到了对应的hw_module_t结构体，
会将其指针放入*module中。看看它的实现。
[cpp] view
plaincopy
124 int hw_get_module(const char *id, const struct hw_module_t **module)
125 {
126 int status;
127 int i;
128 const struct hw_module_t *hmi = NULL;
129 char prop[PATH_MAX];
130 char path[PATH_MAX];
131
132 /*
133 * Here we rely on the fact that calling dlopen multiple times on
134 * the same .so will simply increment a refcount (and not load
135 * a new copy of the library).
136 * We also assume that dlopen() is thread-safe.
137 */
138
139 /* Loop through the configuration variants looking for a module */
140 for (i=0 ; i<HAL_VARIANT_KEYS_COUNT+1 ; i++) {
141 if (i < HAL_VARIANT_KEYS_COUNT) {
142 if (property_get(variant_keys[i], prop, NULL) == 0) { //获取数组<span style="font-family:Arial,Helvetica,sans-serif">variant_keys里的属性值</span>
143 continue;
144 }
145 snprintf(path, sizeof(path), "%s/%s.%s.so",
146 HAL_LIBRARY_PATH, id, prop);//如果开发板叫做fs100，这里就加载system/lib/hw/led.fs100.so
147 } else { snprintf(path, sizeof(path), "%s/%s.default.so",
149 HAL_LIBRARY_PATH, id);//这里默认加载system/lib/hw/led.default.so
150 }
151 if (access(path, R_OK)) {
152 continue;
153 }
154 /* we found a library matching this id/variant */
155 break;
156 }
157
158 status = -ENOENT;
159 if (i < HAL_VARIANT_KEYS_COUNT+1) {
160 /* load the module, if this fails, we're doomed, and we should not try
161 * to load a different variant. */
162 status = load(id, path, module);//load函数是关键，调用load函数打开动态链接库
163 }
164
165 return status;
166 }
上述代码主要是获取动态链接库的路径，并调用load函数去打开指定路径下的库文件，load函数是关键所在。
好，那我们就来解开load函数的神秘面纱！！！
[cpp] view
plaincopy
65 static int load(const char *id,
66 const char *path,
67 const struct hw_module_t **pHmi)
68 {
69 int status;
70 void *handle;
71 struct hw_module_t *hmi;
72
73 /*
74 * load the symbols resolving undefined symbols before
75 * dlopen returns. Since RTLD_GLOBAL is not or'd in with
76 * RTLD_NOW the external symbols will not be global
77 */
78 handle = dlopen(path, RTLD_NOW);
79 if (handle == NULL) {
80 char const *err_str = dlerror();
81 LOGE("load: module=%s\n%s", path, err_str?err_str:"unknown");
82 status = -EINVAL;
83 goto done;
84 }
85
86 /* Get the address of the struct hal_module_info. */
87 const char *sym = HAL_MODULE_INFO_SYM_AS_STR;
88 hmi = (struct hw_module_t *)dlsym(handle, sym);
89 if (hmi == NULL) {
90 LOGE("load: couldn't find symbol %s", sym);
91 status = -EINVAL;
92 goto done;
93 }
94
95 /* Check that the id matches */
96 if (strcmp(id, hmi->id) != 0) {
97 LOGE("load: id=%s != hmi->id=%s", id, hmi->id);
98 status = -EINVAL;
99 goto done;
100 }
101
102 hmi->dso = handle;
103
104 /* success */
105 status = 0;
106
93 }
94
95 /* Check that the id matches */
96 if (strcmp(id, hmi->id) != 0) {
97 LOGE("load: id=%s != hmi->id=%s", id, hmi->id);
98 status = -EINVAL;
99 goto done;
100 }
101
102 hmi->dso = handle;
103
104 /* success */
105 status = 0;
106
107 done:
108 if (status != 0) {
109 hmi = NULL;
110 if (handle != NULL) {
111 dlclose(handle);
112 handle = NULL;
113 }
114 } else {
115 LOGV("loaded HAL id=%s path=%s hmi=%p handle=%p",
116 id, path, *pHmi, handle);
117 }
118
119 *pHmi = hmi;
120
121 return status;
122 }
这里有一个宏HAL_MODULE_INFO_SYM_AS_STR需要注意：
[cpp] view
plaincopy
#define HAL_MODULE_INFO_SYM_AS_STR "HMI"
其中 hmi = (struct hw_module_t *)dlsym(handle, sym);
这里是查找“HMI”这个导出符号，并获取其地址。
看到这里，我们不禁要问，为什么根据“HMI”这个导出符号，就可以从动态链接库中找到结构体hw_module_t呢？？
我们知道，ELF = Executable and Linkable Format，可执行连接格式，是UNIX系统实验室（USL）作为应用程序二进制接口（Application Binary Interface，ABI）而开发和发布的，扩展名为elf。一个ELF头在文件的开始，保存了路线图(road map)，描述了该文件的组织情况。sections保存着object 文件的信息，从连接角度看：包括指令，数据,符号表，重定位信息等等。我们的led.default.so就是一个elf格式的文件。
[cpp] view
plaincopy
linux@ubuntu:~/eclair_2.1_farsight/out/target/product/fs100/system/lib/hw$ file led.default.so
led.default.so: ELF 32-bit LSB shared object, ARM, version 1 (SYSV), dynamically linked, stripped
所以说，我们可以使用unix给我们提供的readelf命令去查看相应的符号信息，就一目了然了！
[cpp] view
plaincopy
linux@ubuntu:~/eclair_2.1_farsight/out/target/product/fs100/system/lib/hw$ readelf -s led.default.so
Symbol table '.dynsym' contains 25 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 00000000 0 NOTYPE LOCAL DEFAULT UND
1: 000004c8 0 SECTION LOCAL DEFAULT 7
2: 00001000 0 SECTION LOCAL DEFAULT 11
3: 00000000 0 FUNC GLOBAL DEFAULT UND ioctl
4: 000006d4 0 NOTYPE GLOBAL DEFAULT ABS __exidx_end
5: 00000000 0 FUNC GLOBAL DEFAULT UND __aeabi_unwind_cpp_pr0
6: 00001178 0 NOTYPE GLOBAL DEFAULT ABS _bss_end__
7: 00000000 0 FUNC GLOBAL DEFAULT UND malloc
8: 00001174 0 NOTYPE GLOBAL DEFAULT ABS __bss_start__
9: 00000000 0 FUNC GLOBAL DEFAULT UND __android_log_print
10: 000006ab 0 NOTYPE GLOBAL DEFAULT ABS __exidx_start
11: 00001174 4 OBJECT GLOBAL DEFAULT 15 fd
12: 000005d5 60 FUNC GLOBAL DEFAULT 7 led_set_off
13: 00001178 0 NOTYPE GLOBAL DEFAULT ABS __bss_end__
14: 00001174 0 NOTYPE GLOBAL DEFAULT ABS __bss_start
15: 00000000 0 FUNC GLOBAL DEFAULT UND memset
16: 00001178 0 NOTYPE GLOBAL DEFAULT ABS __end__
17: 00001174 0 NOTYPE GLOBAL DEFAULT ABS _edata
18: 00001178 0 NOTYPE GLOBAL DEFAULT ABS _end
19: 00000000 0 FUNC GLOBAL DEFAULT UND open
20: 00080000 0 NOTYPE GLOBAL DEFAULT ABS _stack
21: 00001000 128 OBJECT GLOBAL DEFAULT 11 HMI
22: 00001170 0 NOTYPE GLOBAL DEFAULT 14 __data_start
23: 00000000 0 FUNC GLOBAL DEFAULT UND close
24: 00000000 0 FUNC GLOBAL DEFAULT UND free
在21行我们发现，名字就是“HMI”，对应于hw_module_t结构体。再去对照一下HAL的代码。
[cpp] view
plaincopy
const struct led_module_t HAL_MODULE_INFO_SYM = {
common: {
tag: HARDWARE_MODULE_TAG,
version_major: 1,
version_minor: 0,
id: LED_HARDWARE_MODULE_ID,
name: "led HAL module",
author: "farsight",
methods: &led_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模块中的所有想要外部访问到的方法。
在看HAL的编写方法的过程中，会发现整个模块貌似没有一个入口。一般说来模块都要有个入口，比
如应用程序有main函数，可以为加载器进行加载执行，dll文件有dllmain，而对于我们自己写的动态
链接库，我们可以对库中导出的任何符号进行调用。
问题来了，Android中的HAL是比较具有通用性的，需要上层的函数对其进行加载调用，Android的
HAL加载器是如何实现对不同的Hardware Module进行通用性的调用的呢？
带着这个疑问查看Android源码，会发现Android中实现调用HAL是通过hw_get_module实现的。
[cpp] view
plaincopy
int hw_get_module(const char *id, const struct hw_module_t **module);
这是其函数原型，id会指定Hardware的id，这是一个字符串，比如我们比较熟悉的led的id是
#define SENSORS_HARDWARE_MODULE_ID “led”，如果找到了对应的hw_module_t结构体，
会将其指针放入*module中。看看它的实现。
[cpp] view
plaincopy
124 int hw_get_module(const char *id, const struct hw_module_t **module)
125 {
126 int status;
127 int i;
128 const struct hw_module_t *hmi = NULL;
129 char prop[PATH_MAX];
130 char path[PATH_MAX];
131
132 /*
133 * Here we rely on the fact that calling dlopen multiple times on
134 * the same .so will simply increment a refcount (and not load
135 * a new copy of the library).
136 * We also assume that dlopen() is thread-safe.
137 */
138
139 /* Loop through the configuration variants looking for a module */
140 for (i=0 ; i<HAL_VARIANT_KEYS_COUNT+1 ; i++) {
141 if (i < HAL_VARIANT_KEYS_COUNT) {
142 if (property_get(variant_keys[i], prop, NULL) == 0) { //获取数组<span style="font-family:Arial,Helvetica,sans-serif">variant_keys里的属性值</span>
143 continue;
144 }
145 snprintf(path, sizeof(path), "%s/%s.%s.so",
146 HAL_LIBRARY_PATH, id, prop);//如果开发板叫做fs100，这里就加载system/lib/hw/led.fs100.so
147 } else { snprintf(path, sizeof(path), "%s/%s.default.so",
149 HAL_LIBRARY_PATH, id);//这里默认加载system/lib/hw/led.default.so
150 }
151 if (access(path, R_OK)) {
152 continue;
153 }
154 /* we found a library matching this id/variant */
155 break;
156 }
157
158 status = -ENOENT;
159 if (i < HAL_VARIANT_KEYS_COUNT+1) {
160 /* load the module, if this fails, we're doomed, and we should not try
161 * to load a different variant. */
162 status = load(id, path, module);//load函数是关键，调用load函数打开动态链接库
163 }
164
165 return status;
166 }
上述代码主要是获取动态链接库的路径，并调用load函数去打开指定路径下的库文件，load函数是关键所在。
好，那我们就来解开load函数的神秘面纱！！！
[cpp] view
plaincopy
65 static int load(const char *id,
66 const char *path,
67 const struct hw_module_t **pHmi)
68 {
69 int status;
70 void *handle;
71 struct hw_module_t *hmi;
72
73 /*
74 * load the symbols resolving undefined symbols before
75 * dlopen returns. Since RTLD_GLOBAL is not or'd in with
76 * RTLD_NOW the external symbols will not be global
77 */
78 handle = dlopen(path, RTLD_NOW);
79 if (handle == NULL) {
80 char const *err_str = dlerror();
81 LOGE("load: module=%s\n%s", path, err_str?err_str:"unknown");
82 status = -EINVAL;
83 goto done;
84 }
85
86 /* Get the address of the struct hal_module_info. */
87 const char *sym = HAL_MODULE_INFO_SYM_AS_STR;
88 hmi = (struct hw_module_t *)dlsym(handle, sym);
89 if (hmi == NULL) {
90 LOGE("load: couldn't find symbol %s", sym);
91 status = -EINVAL;
92 goto done;
93 }
94
95 /* Check that the id matches */
96 if (strcmp(id, hmi->id) != 0) {
97 LOGE("load: id=%s != hmi->id=%s", id, hmi->id);
98 status = -EINVAL;
99 goto done;
100 }
101
102 hmi->dso = handle;
103
104 /* success */
105 status = 0;
106
93 }
94
95 /* Check that the id matches */
96 if (strcmp(id, hmi->id) != 0) {
97 LOGE("load: id=%s != hmi->id=%s", id, hmi->id);
98 status = -EINVAL;
99 goto done;
100 }
101
102 hmi->dso = handle;
103
104 /* success */
105 status = 0;
106
107 done:
108 if (status != 0) {
109 hmi = NULL;
110 if (handle != NULL) {
111 dlclose(handle);
112 handle = NULL;
113 }
114 } else {
115 LOGV("loaded HAL id=%s path=%s hmi=%p handle=%p",
116 id, path, *pHmi, handle);
117 }
118
119 *pHmi = hmi;
120
121 return status;
122 }
这里有一个宏HAL_MODULE_INFO_SYM_AS_STR需要注意：
[cpp] view
plaincopy
#define HAL_MODULE_INFO_SYM_AS_STR "HMI"
其中 hmi = (struct hw_module_t *)dlsym(handle, sym);
这里是查找“HMI”这个导出符号，并获取其地址。
看到这里，我们不禁要问，为什么根据“HMI”这个导出符号，就可以从动态链接库中找到结构体hw_module_t呢？？
我们知道，ELF = Executable and Linkable Format，可执行连接格式，是UNIX系统实验室（USL）作为应用程序二进制接口（Application Binary Interface，ABI）而开发和发布的，扩展名为elf。一个ELF头在文件的开始，保存了路线图(road map)，描述了该文件的组织情况。sections保存着object 文件的信息，从连接角度看：包括指令，数据,符号表，重定位信息等等。我们的led.default.so就是一个elf格式的文件。
[cpp] view
plaincopy
linux@ubuntu:~/eclair_2.1_farsight/out/target/product/fs100/system/lib/hw$ file led.default.so
led.default.so: ELF 32-bit LSB shared object, ARM, version 1 (SYSV), dynamically linked, stripped
所以说，我们可以使用unix给我们提供的readelf命令去查看相应的符号信息，就一目了然了！
[cpp] view
plaincopy
linux@ubuntu:~/eclair_2.1_farsight/out/target/product/fs100/system/lib/hw$ readelf -s led.default.so
Symbol table '.dynsym' contains 25 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 00000000 0 NOTYPE LOCAL DEFAULT UND
1: 000004c8 0 SECTION LOCAL DEFAULT 7
2: 00001000 0 SECTION LOCAL DEFAULT 11
3: 00000000 0 FUNC GLOBAL DEFAULT UND ioctl
4: 000006d4 0 NOTYPE GLOBAL DEFAULT ABS __exidx_end
5: 00000000 0 FUNC GLOBAL DEFAULT UND __aeabi_unwind_cpp_pr0
6: 00001178 0 NOTYPE GLOBAL DEFAULT ABS _bss_end__
7: 00000000 0 FUNC GLOBAL DEFAULT UND malloc
8: 00001174 0 NOTYPE GLOBAL DEFAULT ABS __bss_start__
9: 00000000 0 FUNC GLOBAL DEFAULT UND __android_log_print
10: 000006ab 0 NOTYPE GLOBAL DEFAULT ABS __exidx_start
11: 00001174 4 OBJECT GLOBAL DEFAULT 15 fd
12: 000005d5 60 FUNC GLOBAL DEFAULT 7 led_set_off
13: 00001178 0 NOTYPE GLOBAL DEFAULT ABS __bss_end__
14: 00001174 0 NOTYPE GLOBAL DEFAULT ABS __bss_start
15: 00000000 0 FUNC GLOBAL DEFAULT UND memset
16: 00001178 0 NOTYPE GLOBAL DEFAULT ABS __end__
17: 00001174 0 NOTYPE GLOBAL DEFAULT ABS _edata
18: 00001178 0 NOTYPE GLOBAL DEFAULT ABS _end
19: 00000000 0 FUNC GLOBAL DEFAULT UND open
20: 00080000 0 NOTYPE GLOBAL DEFAULT ABS _stack
21: 00001000 128 OBJECT GLOBAL DEFAULT 11 HMI
22: 00001170 0 NOTYPE GLOBAL DEFAULT 14 __data_start
23: 00000000 0 FUNC GLOBAL DEFAULT UND close
24: 00000000 0 FUNC GLOBAL DEFAULT UND free
在21行我们发现，名字就是“HMI”，对应于hw_module_t结构体。再去对照一下HAL的代码。
[cpp] view
plaincopy
const struct led_module_t HAL_MODULE_INFO_SYM = {
common: {
tag: HARDWARE_MODULE_TAG,
version_major: 1,
version_minor: 0,
id: LED_HARDWARE_MODULE_ID,
name: "led HAL module",
author: "farsight",
methods: &led_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模块中的所有想要外部访问到的方法。
内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理 
相关文章推荐
- Android--hw_get_module解析
- Android--hw_get_module解析
- Android--hw_get_module解析
- Android应用程序访问linux驱动第五步：回顾hw_get_module
- Android 系统服务的注册以及 getService() 方法源码解析
- Android View中onSave(),onRestore(),getWidth(),getMeasureWidth()方法解析
- Android中Volley框架Get,POST封装使用及自动解析JSON
- Android：Volley解析（一）之GET、POST请求篇
- android客户端从服务器端获取json数据并解析的实现代码get+post
- Android Volley源码 解析（一）之GET、POST请求篇
- Android 关于post、get、pull、delete解析分析
- Android Volley解析（一）之GET、POST请求篇
- Android中hw_get_module函数分析
- [置顶] 无法定位程序输入点K32Get Module File Name Ex于动态链接库KERNEL32.dll上 的错误解析
- [置顶] 针对 android端模拟教务系统登陆，主要针对抓包过程，post，get请求，和解析网页和cookie（一）
- mtk平台hw_get_module分析
- Android之ViewPager.getChildCount()无限自增问题解析
- android中hw_get_module函数分析
- android中通过GET方法接收数据并通过xml解析数据，POST方法向服务器提交数据
- 在android用Google Geocoding API服务解析地址(关键词：android/GPS/Geocoding API/getLocationFrom()返回null)