上一篇我們分析了android 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中，打開這個文件可以看到定義如下：
1 int hw_get_module(const char *id, const struct hw_module_t **module) 2 { 3 int status; 4 int i; 5 const struct hw_module_t *hmi = NULL; 6 char prop[PATH_MAX]; 7 char path[PATH_MAX]; 8 9 /* 10 * Here we rely on the fact that calling dlopen multiple times on 11 * the same .so will simply increment a refcount (and not load 12 * a new copy of the library). 13 * We also assume that dlopen() is thread-safe. 14 */ 15 16 /* Loop through the configuration variants looking for a module */ 17 for (i=0 ; i<HAL_VARIANT_KEYS_COUNT+1 ; i++) { 18 if (i < HAL_VARIANT_KEYS_COUNT) { 19 if (property_get(variant_keys[i], prop, NULL) == 0) {//獲取屬性 20 continue; 21 } 22 snprintf(path, sizeof(path), "%s/%s.%s.so", 23 HAL_LIBRARY_PATH1, id, prop); 24 if (access(path, R_OK) == 0) break;//檢查system路徑是否有庫文件 25 26 snprintf(path, sizeof(path), "%s/%s.%s.so", 27 HAL_LIBRARY_PATH2, id, prop); 28 if (access(path, R_OK) == 0) break;//檢查vender路徑是否有庫文件 29 } else { 30 snprintf(path, sizeof(path), "%s/%s.default.so",//如果都沒有，則使用缺省的 31 HAL_LIBRARY_PATH1, id); 32 if (access(path, R_OK) == 0) break; 33 } 34 } 35 36 status = -ENOENT; 37 if (i < HAL_VARIANT_KEYS_COUNT+1) { 38 /* load the module, if this fails, we're doomed, and we should not try 39 * to load a different variant. */ 40 status = load(id, path, module);//裝載庫，得到module 41 } 42 43 return status; 44 }
看第一行我們知道有兩個參數，第一參數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。
以上就對hal層搜索庫的規則搞清楚了。
下一篇我們將進入load函數，看看共享庫是如何被加載的。