我們知道，google爲了保護硬件廠商的信息，在Android中添加了一層，也就是大名鼎鼎的HAL層。
在看HAL的編寫方法的過程中，會發現整個模塊貌似沒有一個入口。一般說來模塊都要有個入口，比如應用程序有main函數，可以爲加載器進行加載執行，dll文件有dllmain，而對於我們自己寫的動態鏈接庫，我們可以對庫中導出的任何符號進行調用。
問題來了，Android中的HAL是比較具有通用性的，需要上層的函數對其進行加載調用，Android的HAL加載器是如何實現對不同的Hardware Module進行通用性的調用的呢？
帶着這個疑問查看Android源碼，會發現Android中實現調用HAL是通過hw_get_module實現的。
[cpp] view plaincopy
1. 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
1. 124 int hw_get_module(const char *id, const struct hw_module_t **module)
2. 125 {
3. 126 int status;
4. 127 int i;
5. 128 const struct hw_module_t *hmi = NULL;
6. 129 char prop[PATH_MAX];
7. 130 char path[PATH_MAX];
8. 131
9. 132 /*
10. 133 * Here we rely on the fact that calling dlopen multiple times on
11. 134 * the same .so will simply increment a refcount (and not load
12. 135 * a new copy of the library).
13. 136 * We also assume that dlopen() is thread-safe.
14. 137 */
15. 138
16. 139 /* Loop through the configuration variants looking for a module */
17. 140 for (i=0 ; i<HAL_VARIANT_KEYS_COUNT+1 ; i++) {
18. 141 if (i < HAL_VARIANT_KEYS_COUNT) {
19. 142 if (property_get(variant_keys[i], prop, NULL) == 0) { //獲取數組variant_keys裏的屬性值
20.
21. 143 continue;
22. 144 }
23. 145 snprintf(path, sizeof(path), "%s/%s.%s.so",
24. 146 HAL_LIBRARY_PATH, id, prop);//如果開發板叫做fs100，這裏就加載system/lib/hw/led.fs100.so
25. 147 } else { snprintf(path, sizeof(path), "%s/%s.default.so",
26. 149 HAL_LIBRARY_PATH, id);//這裏默認加載system/lib/hw/led.default.so
27. 150 }
28. 151 if (access(path, R_OK)) {
29. 152 continue;
30. 153 }
31. 154 /* we found a library matching this id/variant */
32. 155 break;
33. 156 }
34. 157
35. 158 status = -ENOENT;
36. 159 if (i < HAL_VARIANT_KEYS_COUNT+1) {
37. 160 /* load the module, if this fails, we're doomed, and we should not try
38. 161 * to load a different variant. */
39. 162 status = load(id, path, module);//load函數是關鍵，調用load函數打開動態鏈接庫
40. 163 }
41. 164
42. 165 return status;
43. 166 }
上述代碼主要是獲取動態鏈接庫的路徑，並調用load函數去打開指定路徑下的庫文件，load函數是關鍵所在。
好，那我們就來解開load函數的神祕面紗！！！
[cpp] view plaincopy
1. 65 static int load(const char *id,
2. 66 const char *path,
3. 67 const struct hw_module_t **pHmi)
4. 68 {
5. 69 int status;
6. 70 void *handle;
7. 71 struct hw_module_t *hmi;
8. 72
9. 73 /*
10. 74 * load the symbols resolving undefined symbols before
11. 75 * dlopen returns. Since RTLD_GLOBAL is not or'd in with
12. 76 * RTLD_NOW the external symbols will not be global
13. 77 */
14. 78 handle = dlopen(path, RTLD_NOW);
15. 79 if (handle == NULL) {
16. 80 char const *err_str = dlerror();
17. 81 LOGE("load: module=%s\n%s", path, err_str?err_str:"unknown");
18. 82 status = -EINVAL;
19. 83 goto done;
20. 84 }
21. 85
22. 86 /* Get the address of the struct hal_module_info. */
23. 87 const char *sym = HAL_MODULE_INFO_SYM_AS_STR;
24. 88 hmi = (struct hw_module_t *)dlsym(handle, sym);
25. 89 if (hmi == NULL) {
26. 90 LOGE("load: couldn't find symbol %s", sym);
27. 91 status = -EINVAL;
28. 92 goto done;
29. 93 }
30. 94
31. 95 /* Check that the id matches */
32. 96 if (strcmp(id, hmi->id) != 0) {
33. 97 &nnbsp; LOGE("load: id=%s != hmi->id=%s", id, hmi->id);
34. 98 status = -EINVAL;
35. 99 goto done;
36. 100 }
37. 101
38. 102 hmi->dso = handle;
39. 103
40. 104 /* success */
41. 105 status = 0;
42. 106
43. 93 }
44. 94
45. 95 /* Check that the id matches */
46. 96 if (strcmp(id, hmi->id) != 0) {
47. 97 LOGE("load: id=%s != hmi->id=%s", id, hmi->id);
48. 98 status = -EINVAL;
49. 99 goto done;
50. 100 }
51. 101
52. 102 hmi->dso = handle;
53. 103
54. 104 /* success */
55. 105 nbsp; status = 0;
56. 106
57. 107 done:
58. 108 if (status != 0) {
59. 109 hmi = NULL;
60. 110 if (handle != NULL) {
61. 111 dlclose(handle);
62. 112 handle = NULL;
63. 113 }
64. 114 } else {
65. 115 LOGV("loaded HAL id=%s path=%s hmi=%p handle=%p",
66. 116 id, path, *pHmi, handle);
67. 117 }
68. 118
69. 119 *pHmi = hmi;
70. 120
71. 121 return status;
72. 122 }
這裏有一個宏HAL_MODULE_INFO_SYM_AS_STR需要注意：
[cpp] view plaincopy
1. #define HAL_MODULE_INFO_SYM_AS_STR "HMI"
2. #define HAL_MODULE_INFO_SYM HMI //每個Hal so 中國hw_module_t，及sensor_module_t等變種的實例都是以HMI命令，被編譯到ELF so文件中。
其中hmi = (structhw_module_t *)dlsym(handle, sym);
這裏是查找“HMI”這個導出符號，並獲取其地址。// 通過HMI字符串關鍵字從elf中找到hw_moudle實例所在地址。
看到這裏，我們不禁要問，爲什麼根據“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
1. linux@ubuntu:~/eclair_2.1_farsight/out/target/product/fs100/system/lib/hw$ file led.default.so
2. led.default.so: ELF 32-bit LSB shared object, ARM, version 1 (SYSV), dynamically linked, stripped
所以說，我們可以使用unix給我們提供的readelf命令去查看相應的符號信息，就一目瞭然了！
[cpp] view plaincopy
1. linux@ubuntu:~/eclair_2.1_farsight/out/target/product/fs100/system/lib/hw$
readelf -s led.default.so
2.
3. Symbol table '.dynsym' contains 25 entries:
4. Num: Value Size Type Bind Vis Ndx Name
5. 0: 00000000 0 NOTYPE LOCAL DEFAULT UND
6. 1: 000004c8 0 SECTION LOCAL DEFAULT 7
7. 2: 00001000 0 SECTION LOCAL DEFAULT 11
8. 3: 00000000 0 FUNC GLOBAL DEFAULT UND ioctl
9. 4: 000006d4 0 NOTYPE GLOBAL DEFAULT ABS __exidx_end
10. 5: 00000000 0 FUNC GLOBAL DEFAULT UND __aeabi_unwind_cpp_pr0
11. 6: 00001178 0 NOTYPE GLOBAL DEFAULT ABS _bss_end__
12. 7: 00000000 0 FUNC GLOBAL DEFAULT UND malloc
13. 8: 00001174 0 NOTYPE GLOBAL DEFAULT ABS __bss_start__
14. 9: 00000000 0 FUNC GLOBAL DEFAULT UND __android_log_print
15. 10: 000006ab 0 NOTYPE GLOBAL DEFAULT ABS __exidx_start
16. 11: 00001174 4 OBJECT GLOBAL DEFAULT 15 fd
17. 12: 000005d5 60 FUNC GLOBAL DEFAULT 7 led_set_off
18. 13: 00001178 0 NOTYPE nbsp; GLOBAL DEFAULT ABS __bss_end__
19. 14: 00001174 0 NOTYPE GLOBAL DEFAULT ABS __bss_start
20. 15: 00000000 0 FUNC GLOBAL DEFAULT UND memset
21. 16: 00001178 0 NOTYPE GLOBAL DEFAULT ABS __end__
22. 17: 00001174 0 NOTYPE GLOBAL DEFAULT ABS _edata
23. 18: 00001178 0 NOTYPE GLOBAL DEFAULT ABS _end
24. 19: 00000000 0 FUNC GLOBAL DEFAULT UND open
25. 20: 00080000 0 NOTYPE GLOBAL DEFAULT ABS _stack
26. 21: 00001000 128 OBJECT GLOBAL DEFAULT 11 HMI
27. 22: 00001170 0 NOTYPE GLOBAL DEFAULT 14 __data_start
28. 23: 00000000 0 FUNC GLOBAL DEFAULT UND close
29. 24: 00000000 0 FUNC GLOBAL DEFAULT UND free
在21行我們發現，名字就是“HMI”，對應於hw_module_t結構體。再去對照一下HAL的代碼。
[cpp] view plaincopy
1. const struct led_module_t HAL_MODULE_INFO_SYM = {
2. common: {
3. tag: HARDWARE_MODULE_TAG,
4. version_major: 1,
5. version_minor: 0,
6. id: LED_HARDWARE_MODULE_ID,
7. name: "led HAL module",
8. author: "farsight",
9. methods: &led_module_methods,
10. },
11.
12. };
這裏定義了一個名爲HAL_MODULE_INFO_SYM的copybit_module_t的結構體，common成員爲hw_module_t類型。注意這裏的HAL_MODULE_INFO_SYM變量必須爲這個名字，這樣編譯器纔會將這個結構體的導出符號變爲“HMI”，這樣這個結構體才能被dlsym函數找到！
綜上，我們知道了andriod HAL模塊也有一個通用的入口地址，這個入口地址就是HAL_MODULE_INFO_SYM變量，通過它，我們可以訪問到HAL模塊中的所有想要外部訪問到的方法。