久久婷婷香蕉热狠狠综合,精品无码国产自产拍在线观看蜜,寡妇房东在做爰3,中文字幕日本人妻久久久免费,国产成人精品三上悠亚久久

上(shang)(shang)一篇我們分(fen)析了(le)android HAL層(ceng)的主要的兩個結構體hw_module_t(硬件模(mo)塊(kuai))和hw_device_t(硬件設備)的成員，下面我們來(lai)具體看(kan)看(kan)上(shang)(shang)層(ceng)app到底是怎么實(shi)現操作硬件的?

我們知(zhi)道(dao)，一些(xie)硬(ying)(ying)件(jian)廠商不(bu)愿意將自己的(de)(de)一些(xie)核心(xin)代(dai)碼開放出(chu)去，所以(yi)將這(zhe)(zhe)些(xie)代(dai)碼放到(dao)HAL層(ceng)，但是(shi)怎(zen)么(me)保證它不(bu)開放呢(ni)?HAL層(ceng)代(dai)碼不(bu)是(shi)也讓大(da)家知(zhi)道(dao)下載嗎(ma)?其(qi)實硬(ying)(ying)件(jian)廠商的(de)(de)HAL核心(xin)代(dai)碼是(shi)以(yi)共享(xiang)(xiang)庫的(de)(de)形式(shi)出(chu)現的(de)(de)，每次在需要的(de)(de)時(shi)候，hal會自動加(jia)載調用相(xiang)關(guan)共享(xiang)(xiang)庫。那么(me)是(shi)怎(zen)么(me)加(jia)載找到(dao)某(mou)一硬(ying)(ying)件(jian)設備對應的(de)(de)共享(xiang)(xiang)庫的(de)(de)呢(ni)?這(zhe)(zhe)也是(shi)我們這(zhe)(zhe)篇都要說的(de)(de)。

上(shang)層(ceng)app通過jni調用(yong)(yong)hal層(ceng)的(de)hw_get_module函數(shu)(shu)獲取硬件模塊，這個(ge)函數(shu)(shu)是上(shang)層(ceng)與hal打交(jiao)道的(de)入(ru)口(kou)。所(suo)以(yi)如果我們(men)(men)以(yi)程序調用(yong)(yong)執行的(de)流程去看源碼(ma)的(de)話，這個(ge)函數(shu)(shu)就是hal層(ceng)第一個(ge)被調用(yong)(yong)的(de)函數(shu)(shu)，下面我們(men)(men)就

從這(zhe)個函數(shu)開始，沿著程序執行的(de)流程走下去。

hw_get_module函數定(ding)義在/hardware/libhardware/hardware.c中，打開這個文件可(ke)以看到定(ding)義如下：

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

18 if (i < HAL_VARIANT_KEYS_COUNT) {

19 if (property_get(variant_keys[i], prop, NULL) == 0) {//獲取屬(shu)性(xing)

20 continue;

21 }

22 snprintf(path, sizeof(path), &quot;%s/%s.%s.so",

23 HAL_LIBRARY_PATH1, id, prop);

24 if (access(path, R_OK) == 0) break;//檢查system路徑是否有庫文(wen)件

25

26 snprintf(path, sizeof(path), "%s/%s.%s.so",

27 HAL_LIBRARY_PATH2, id, prop);

28 if (access(path, R_OK) == 0) break;//檢(jian)查vender路(lu)徑是否有庫文(wen)件

29 } else {

30 snprintf(path, sizeof(path), "%s/%s.default.so";,//如果都沒有(you)，則(ze)使用(yong)缺(que)省的

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 }

看(kan)第(di)(di)一行(xing)我們知道有(you)兩個(ge)(ge)參數，第(di)(di)一參數id就是要獲取的(de)硬件(jian)模塊的(de)id，第(di)(di)二個(ge)(ge)參數module就是我們想得到的(de)硬件(jian)模塊結構(gou)體的(de)指針。

所(suo)以(yi)可以(yi)看出，上層首先(xian)給hal需要(yao)獲取的硬(ying)(ying)件模塊(kuai)的id，hw_get_module函數根據這(zhe)個id去查找匹配(pei)和這(zhe)個id對應的硬(ying)(ying)件模塊(kuai)結構(gou)體的。

下面看(kan)看(kan)怎么找(zhao)的。

17行有個(ge)for循環，上(shang)限是HAL_VARIANT_KEYS_COUNT+1，那(nei)么這個(ge)HAL_VARIANT_KEYS_COUNT是什么呢?查(cha)看(kan)同文件下找到有：

static const int HAL_VARIANT_KEYS_COUNT =

 (sizeof(variant_keys)/sizeof(variant_keys[0]));

原來它是ariant_keys這個數(shu)(shu)組的元素(su)個數(shu)(shu)。那么這個數(shu)(shu)組又是什么呢?在本文件找，有：

/**

* There are a set of variant filename for modules. The form of the filename

* is ".variant.so" so for the led module the Dream variants

* of base "ro.product.board", &quot;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"

};

可以看(kan)到它(ta)其實是個字(zi)符串數(shu)組。站且不知道干什么的。繼續看(kan)hw_get_module函數(shu)，進入for循環里面，看(kan)22行，其實它(ta)是將(jiang)HAL_LIBRARY_PATH1, id, prop這(zhe)三個串拼(pin)湊一個路(lu)徑(jing)出來，

HAL_LIBRARY_PATH1定義如下(xia)：

/** Base path of the hal modules */

#define HAL_LIBRARY_PATH1 "/system/lib/hw"

#define HAL_LIBRARY_PATH2 "/vendor/lib/hw"

id是上層提供的(de)(de)(de)，prop這(zhe)個(ge)變量的(de)(de)(de)值(zhi)是前面19行property_get(variant_keys[i], prop, NULL)函(han)數(shu)獲(huo)取(qu)到(dao)的(de)(de)(de)，其實(shi)這(zhe)個(ge)函(han)數(shu)是通過ariant_keys數(shu)組的(de)(de)(de)的(de)(de)(de)屬性查(cha)找到(dao)系統中對應的(de)(de)(de)變種名稱。不同的(de)(de)(de)平(ping)臺獲(huo)取(qu)到(dao)prop值(zhi)是不一樣的(de)(de)(de)。

假如在獲(huo)取(qu)到(dao)的prop值是tout，需要(yao)獲(huo)取(qu)的硬件模塊(kuai)的id是leds，那(nei)么后path組成的串是/system/lib/hw/leds.tout.so。

后面(mian)24行access是(shi)檢查(cha)這個路徑下是(shi)否存在，如果有就break，跳出(chu)循(xun)環。如果沒有，繼(ji)續走下面(mian)，

可以看到下面(mian)幾行和剛才(cai)形式差不多，

snprintf(path, sizeof(path), "%s/%s.%s.so", HAL_LIBRARY_PATH2, id, prop);

if (access(path, R_OK) == 0) break;//檢查(cha)vender路(lu)徑是否有庫文件(jian)

結合 HAL_LIBRARY_PATH2 為"/vendor/lib/hw"，假設同樣獲取到的(de)prop值是(shi)tout，需要獲取的(de)硬件(jian)模塊的(de)id是(shi)leds，這(zhe)種(zhong)情(qing)況下path拼出來(lai)的(de)值是(shi)/vender/lib/hw/leds.tout.so,然后在判(pan)斷文件(jian)是(shi)否存在。如果存在跳出循(xun)環。

從(cong)以上分析，其實這就是(shi)hal層(ceng)搜索動(dong)態(tai)共享庫(ku)的方式，從(cong)中我們可以得(de)到兩點：

1.動態共享庫(ku)一般放在 "/system/lib/hw"和"/vendor/lib/hw"這(zhe)兩(liang)個路徑(jing)下。

2.動態(tai)庫的(de)名(ming)稱是以(yi)"id.variant.so"的(de)形式命名(ming)的(de)，其(qi)中(zhong)id為(wei)(wei)上層提供，中(zhong)間variant為(wei)(wei)變種名(ming)稱，是隨(sui)系統平臺變化的(de)。

接著，從29到32行我們可(ke)以看到，當所有變種名稱形(xing)式(shi)的包都(dou)不存在時，就(jiu)以"id.default.so"形(xing)式(shi)包名查找是否存在。

37行， if (i < HAL_VARIANT_KEYS_COUNT+1)，如果i小于變種(zhong)名(ming)稱(cheng)數組的(de)話，表示找到了對應的(de)庫，那么38行load(id, path, module);//裝載庫，得到module。

以上(shang)就對hal層搜索庫的規則搞清楚了。

下一(yi)篇我們(men)將進(jin)入load函數(shu)，看(kan)(kan)看(kan)(kan)共(gong)享庫是如何被加(jia)載的。