Android HAL

 

作為一個搞android驅動或者說搞底層的人，我覺得對於hal那是必須要掌握的，而且必須達到一定深度，於是我總結了一下，將整個自己的分析思路寫下來。 

主要是看android源代碼，根據源代碼得到的思路。(看源代碼比看什么著作書籍都管用) android HAL是什么？為什么有它？ 
硬件抽象層是介於android內核kernel和上層之間的抽象出來的一層結構。他是對linux驅動的一個封裝，對上層提供統一接口，上層應用不必知道下層硬件具體怎么實現工作的，它屏蔽了底層的實現細節。 
它在整個android架構中的位置如下圖所示： 
 
傳統的linux對硬件的操作基本上在內核空間的linux驅動程序中實現了，那么現在為什么那么多此一舉把對硬件的操作分為兩部分，hal和linux驅動呢？ 
而且hal屬於用戶空間，linux驅動屬於內核空間。其實並不多余。那么為什么要高出這么個東西，理由是很多的： 
1.谷歌搭好了hal的框架，為上層framework打通過jni調用hal提供了統一的api，硬件開發商或者移植人員只需要按照框架開發即可，無需話費精力在與上層的交互上的實現上，將精力放在hal層本身的實現上即可。 
2.從商業角度，許多硬件廠商不願意將自己硬件相關一些核心的東西開源出去，假如將對自己硬件的驅動程序全部放入內核空間驅動程序實現，那么必須遵循GPL協議，是必需開源的。有了HAL層之后，他們可以把一些核心的算法之類的東西的實現放在HAL層，而hal層位於用戶空間，不屬於linux內核，和android源碼一樣遵循的是appache協議，這個是可以開源或者不開的。   
搞清楚了hal的存在意義，下面來根據hal層源碼分析一下hal到底是怎么樣個架構和實現原理，深入剖析一下

 

android hal層的代碼主要位於/hardware/libhardware下面我們從上往下走。 在hal層中，各類硬件的都是以硬件模塊的形式描述的hal層中是用hw_module_t結構體來描述的，而每一類硬件模塊中又有各個獨立的硬件，hal中是用hw_device_t結構體來描述的。 
上層app通過jni調用硬件時，首先得獲取到hw_module_t結構體，也即是硬件模塊，有了這個才能再對硬件進行操作。那么我們來看看看看這兩個結構體定義是什么樣子的。 它們的定義在/hardware/libhardware/include/hardware/hardware.h里面。 a.  hw_module_t表示硬件模塊，它主要包含了一些硬件模塊的信息，結構體的定義：

 
/** 
 * Every hardware module must have a data structure named HAL_MODULE_INFO_SYM 
 * and the fields of this data structure must begin with hw_module_t  * followed by module specific information.  */ 

typedef struct hw_module_t { 
    /** tag must be initialized to HARDWARE_MODULE_TAG */    

uint32_t tag;  //tag，根據引文注釋可以看到必須被初始化為HARDWARE_MODULE_TAG  
    /** major version number for the module */    

uint16_t version_major;//主版本號  
    /** minor version number of the module */     

uint16_t version_minor;//次版本號  
    /** Identifier of module */ 
const char *id;//模塊id字符串     http://www.qqtop2.com      /** Name of this module */     

const char *name;//模塊名  
    /** Author/owner/implementor of the module */     

const char *author;//作者  
    /** Modules methods */ 
struct hw_module_methods_t* methods;//硬件模塊方法結構體  
    /** module's dso */ 
 void* dso;//打開硬件模塊的庫時得到的句柄 

 

    /** padding to 128 bytes, reserved for future use */    

 uint32_t reserved[32-7];  
} hw_module_t; 
 
 前面tag，name那幾個成員屬性就不說了，看了注釋相信大家都知道了，下面看看hw_module_methods_t,這個指針methods它指向的是與本硬件模塊相關的方法的結構體，里面不用看可以猜出肯定有一些函數指針，但是它里面只有一個函數指針。可以看看定義： 
1 typedef struct hw_module_methods_t { 

2     /** Open a specific device */ 
3     int (*open)(const struct hw_module_t* module, const char* id,//打開硬件設備函數指針 
4             struct hw_device_t** device); 

5  

6 } hw_module_methods_t; 
我們可以看到確實只有一個函數指針，open它是打開硬件模塊中硬件設備的函數。 然后是成員void* dso，它是打開硬件模塊相關的額設備之后返回的句柄給它，這個在后面看hw_get_module函數源碼的時候你就會明白。 
b.  下面我們再來看看hw_device_t結構體,這個結構體主要是用來描述模塊中硬件設備的屬性信息什么的。一個硬件模塊可能有多個硬件設備。 
比如說，傳感器模塊，sensor_module,是一個硬件模塊，但是手機中的傳感器就對應的有好多種，比如加速度acc_sensor,磁傳感器M_sensor等，那么他們都屬於sensor_module,但是他們有都有自己的 
hw_device_t結構體來描述。hw_device_t定義：  
 1 /** 
 2  * Every device data structure must begin with hw_device_t  

 3  * followed by module specific public methods and attributes.  

 4  */ 
 5 typedef struct hw_device_t { 
 6     /** tag must be initialized to HARDWARE_DEVICE_TAG */  

 7     uint32_t tag;   //設備tag  

 8     http://mingzi.78name.com  
 9     /** version number for hw_device_t */ 

10     uint32_t version;//版本 

11  
12     /** reference to the module this device belongs to */  

13     struct hw_module_t* module;//本設備歸屬的硬件模塊 

14  
15     /** padding reserved for future use */ 

16     uint32_t reserved[12];//保留 

17  
18     /** Close this device */ 
19     int (*close)(struct hw_device_t* device);//關閉設備的函數指針 

20  
21 } hw_device_t; 
 
其中，第三個成員module指向的是這個設備歸屬的硬件模塊結構體。 最后一個函數指針close指向的肯定是關閉設備的函數。   
恩，到此，hal的主要的兩個結構體講完了，下次我們繼續，將結合源碼，看看hal層到底是怎么工作的，看看上層怎么獲取到硬件模塊，硬件設備的，到底是怎么加載解析動態共享庫的。 
上一篇我們分析了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拼出來的值是
/ender/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層搜索庫的規則搞清楚了。