Android硬件抽象層(HAL)深刻剖析(二)

時間 2019-12-06

原文原文鏈接

上一篇咱們分析了android HAL層的主要的兩個結構體hw_module_t(硬件模塊)和hw_device_t(硬件設備)的成員，下面咱們來具體看看上層app究竟是怎麼實現操做硬件的？android

咱們知道，一些硬件廠商不肯意將本身的一些核心代碼開放出去，因此將這些代碼放到HAL層，可是怎麼保證它不開放呢？HAL層代碼不是也讓你們知道下載嗎？其實硬件廠商的HAL核心代碼是以共享庫的形式出現的，每次在須要的時候，hal會自動加載調用相關共享庫。那麼是怎麼加載找到某一硬件設備對應的共享庫的呢？這也是咱們這篇都要說的。數組

上層app經過jni調用hal層的hw_get_module函數獲取硬件模塊，這個函數是上層與hal打交道的入口。因此若是咱們以程序調用執行的流程去看源碼的話，這個函數就是hal層第一個被調用的函數，下面咱們就app

從這個函數開始，沿着程序執行的流程走下去。函數

hw_get_module函數定義在/hardware/libhardware/hardware.c中，打開這個文件能夠看到定義以下：oop

 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就是咱們想獲得的硬件模塊結構體的指針。this

因此能夠看出，上層首先給hal須要獲取的硬件模塊的id，hw_get_module函數根據這個id去查找匹配和這個id對應的硬件模塊結構體的。spa

下面看看怎麼找的。指針

17行有個for循環，上限是HAL_VARIANT_KEYS_COUNT+1，那麼這個HAL_VARIANT_KEYS_COUNT是什麼呢？查看同文件下找到有：orm

static const int HAL_VARIANT_KEYS_COUNT =
(sizeof(variant_keys)/sizeof(variant_keys[0]));ip

原來它是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"
};