Android硬體抽象層(HAL)深入剖析(二)

標籤：第一個   入口   函數定義   time   預設   ons   efault   boa   名稱   

上一篇我們分析了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 p="">

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函數，看看共用庫是如何被載入的。

Android硬體抽象層(HAL)深入剖析(二)