深入淺出 – Android系統移植與平台開發（八）－ HAL Stub架構分析

1.      HAL Stub架構分析

HAL stub的架構比較簡單，三個結構體、兩個常量、一個函數，簡稱321架構，它的定義在：

@hardware/libhardware/include/hardware/hardware.h

@hardware/libhardware/hardware.c

/* 每一個硬體都通過hw_module_t來描述，我們稱之為一個硬體對象。你可以去“繼承”這個hw_module_t，然後擴充自己的屬性，硬體對象必須定義為一個固定的名字：HMI，即：Hardware Module Information的簡寫，每一個硬體對象裡都封裝了一個函數指標open用於開啟該硬體，我們理解為硬體對象的open方法，open調用後返回這個硬體對應的Operation interface。*/struct hw_module_t｛uint32_t tag;// 該值必須聲明為HARDWARE_MODULE_TAGuint16_t version_major;// 主要版本號uint16_t version_minor; // 次版本號碼const char *id;//硬體id名，唯一標識moduleconst char *name;// 硬體module名字const char * author;// 作者struct hw_module_methods_t* methods;//指向封裝有open函數指標的結構體void* dso;// module’s dsouint32_t reserved[32-7];// 128位元組補齊｝;/* 硬體對象的open方法描述結構體，它裡面只有一個元素：open函數指標*/struct hw_module_methods_t{// 只封裝了open函數指標int (*open)(const struct hw_module_t* module, const char * id,struct hw_device_t** device);};/*硬體對象hw_module_t的open方法返回該硬體的Operation interface，它由hw_device_t結構體來描述，我們稱之為：該硬體的操作介面*/struct hw_device_t{uint32_t tag;// 必須賦值為HARDWARE_DEVICE_TAGuint32_t version;// 版本號碼struct hw_module_t* module;// 該裝置操作屬於哪個硬體對象，可以看成硬體操作介面與硬體對象的聯絡uint32_t reserved[12];// 位元組補齊int (*close)(struct hw_device_t* device);// 該裝置的關閉函數指標，可以看做硬體的close方法};

上述三個結構之間關係緊密，每個硬體對象由一個hw_module_t來描述，只要我們拿到了這個硬體對象，就可以調用它的open方法，返回這個硬體對象的硬體操作介面，然後就可以通過這些硬體操作介面來間接操作硬體了。只不過，open方法被struct hw_module_methods_t結構封裝了一次，硬體操作介面被hw_device_t封裝了一次而已。

那使用者程式如何才能拿到硬體對象呢？

答案是通過硬體id名來拿。

我們來看下321架構裡的：兩個符號常量和一個函數：

// 這個就是HAL Stub對象固定的名字#define HAL_MODULE_INFO_SYM         HMI// 這是字串形式的名字#define HAL_MODULE_INFO_SYM_AS_STR  "HMI"//這個函數是通過硬體名來獲得硬體HAL Stub對象int hw_get_module(const char *id, const struct hw_module_t **module);

當使用者調用hw_get_module函數時，第一個參數傳硬體id名，那麼這個函數會從當前系統註冊的硬體對象裡尋找傳遞過來的id名對應的硬體對象，然後返回之。

從調用者的角度，我們基本上沒有什麼障礙了，那如何註冊一個硬體對象呢？

很簡單，只需要聲明一個結構體即可，看下面這個Led Stub註冊的例子：

const struct led_module_t HAL_MODULE_INFO_SYM = {    common: {// 初始化父結構hw_module_t成員        tag: HARDWARE_MODULE_TAG,    version_major: 1,    version_minor: 0,    id: LED_HARDWARE_MODULE_ID,    name: "led HAL Stub",    author: "farsight",    methods: &led_module_methods,}, // 擴充屬性放在這兒};

對，就這麼簡單，我們只需要聲明一個結構體led_moduel_t，起名叫HAL_MODULE_INFO_SYM，也就是固定的名字：HMI，然後將這個結構體填充好就行了。led_module_t又是什麼結構體類型啊？前面分析hw_modult_t類型時說過，我們可以“繼承”hw_module_t類型，建立自己的硬體對象，然後自己再擴充特有屬性，這裡的led_module_t就是“繼承”的hw_module_t類型。注意，繼承加上了雙引號，因為在C語言裡沒有繼承這個概念：

struct led_module_t {struct hw_module_t common;};

結構體led_module_t封裝了hw_module_t結構體，也就是說led_module_t這個新（子）結構體包含了舊（父）結構體，在新結構體裡可以再擴充一些新的成員。結構體本身就具有封裝特性，這不就是物件導向的封裝和繼承嗎！為了顯得專業點，我們用UML描述一下：

在上面的類圖裡，把hw_module_methods_t裡封裝的open函數指標指標寫成open方法。

該open方法既：methods，自然也被子結構體給“繼承”下來，我們將它初始化為led_module_methods的地址，該結構是hw_module_methods_t類型的，其聲明代碼如下：

static struct hw_module_methods_t led_module_methods = {    open: led_device_open  };

簡潔，我喜歡！！，它裡面僅有的open成員是個函數指標，它被指向led_device_open函數:

static int led_device_open(const struct hw_module_t* module, const char* name,struct hw_device_t** device){struct led_device_t *led_device;LOGI("%s E ", __func__);led_device = (struct led_device_t *)malloc(sizeof(*led_device));memset(led_device, 0, sizeof(*led_device)); // init hw_module_tled_device->common.tag= HARDWARE_DEVICE_TAG;led_device->common.version = 0;led_device->common.module= module;led_device->common.close = led_device_close; // init operation interfaceled_device->set_on= led_set_on;led_device->set_off= led_set_off;led_device->get_led_count = led_getcount;*device= (struct hw_device_t *)led_device;if((fd=open("/dev/leds",O_RDWR))==-1){LOGI("open error");return -1;}elseLOGI("open ok\n");return 0;}

led_device_open函數的功能：

Ø  分配硬體裝置操作結構體led_device_t，該結構體描述硬體操作行為

Ø  初始化led_device_t的父結構體hw_device_t成員

Ø  初始化led_device_t中擴充的操作介面

Ø  開啟裝置，將led_device_t結構體以父結構體類型返回（物件導向裡的多態）

hw_module_t與hw_module_methods_t及硬體open函數的關係如下：

我們來看下led_device_t和其父結構體hw_device_t的關係：

struct led_device_t {struct hw_device_t common;   // led_devict_t的父結構，它裡面只封裝了close方法// 下面三個函數指標是子結構led_device_t對父結構hw_device_t的擴充，可以理解為子類擴充了父類增加了三個方法int (*getcount_led)(struct led_device_t *dev);int (*set_on)(struct led_device_t *dev);int (*set_off)(struct led_device_t *dev);};

用UML類圖來表示：

由類圖可知，led_device_t擴充了三個介面：seton()， setoff()，get_led_count()。

那麼剩下的工作就是實現子結構中新擴充的三個介面了：

static int led_getcount(struct led_control_device_t*dev){         LOGI("led_getcount");         return 4;} static int led_set_on(struct led_control_device_t *dev){            LOGI("led_set_on");         ioctl(fd,GPG3DAT2_ON,NULL);         return 0;} static int led_set_off(struct led_control_device_t*dev){         LOGI("led_set_off");         ioctl(fd,GPG3DAT2_OFF,NULL);         return 0;}

這三個介面函數直接和底層驅動打交道去控制硬體，具體驅動部分我們不去講，那是另外一個體系了。

總結一下：

我們有一個硬體id名，通過這個id調用hw_get_module(char*id, struct hw_module_t **module),這個函數尋找註冊在當前系統中與id對應的硬體對象並返回之，硬體對象裡有個通過hw_module_methods_t結構封裝的open函數指標，回調這個open函數，它返回封裝有硬體操作介面的led_device_t結構體，這樣我們可以通過這個硬體介面去間接的訪問硬體了。

在這個過程中hw_get_module返回的是子結構體類型led_module_t，雖然函數的第二個參數類型為hw_module_t的父類型，這裡用到了物件導向裡的多態的概念。

下面還有一個問題我們沒有解決，為什麼我們聲明了一個名字為HMI結構體後，它就註冊到了系統裡？hw_get_module函數怎麼找到並返回led_module_t描述的硬體對象的？

殺雞取卵找HAL Stub

如果要知道為什麼通過聲明結構體就將HALStub註冊到系統中，最好的方法是Crowdsourced Security Testing道怎麼樣通過hw_get_module_t來找到註冊的硬體對象。

我們分析下hw_get_module函數的實現：

@hardware/libhardware/hardware.c

static const char *variant_keys[] = {“ro.hardware”,“ro.product.board”,“ro.board.platform”,“ro.arch”};// 由上面定義的字串數組可知，HAL_VARIANT_KEYS_COUNT的值為4struct constint HAL_VARIANT_KEYS_COUNT = (sizeof(variant_keys)/sizeof(variant_keys[0]));int hw_get_module(const char *id, const struct hw_module_t **module){// 調用3個參數的hw_get_module_by_class函數return hw_get_module_by_class(id, NULL, module);}int hw_get_module_by_class(const char *class_id, const char *inst, const struct hw_module_t **module){int status;int i;// 聲明一個hw_module_t指標變數hmiconst struct hw_module_t *hmi = NULL;char prop[PATH_MAX};char path[PATH_MAX];char name[PATH_MAX];// 由前面調用函數可知，inst ＝ NULL，執行else部分，將硬體id名拷貝到name數組裡if(inst)snprintf(name, PATH_MAX, “%s.%s”, class_id, inst);elsestrlcpy(name, class_id, PATH_MAX);// i 迴圈5次for(i=0; i<HAL_VARIANT_KEYS_COUNT+1; i++){if(i<HAL_VARIANT_KEYS_COUNT){// 從系統屬性裡依次尋找前面定義的4個屬性的值，找其中一個後，執行後面代碼，找不到，進入else部分執行if(property_get(variant_keys[i], prop, NULL) == 0){continue;}// 找到一個屬性值prop後，拼字path的值為：/vendor/lib/hw/硬體id名.prop.sosnprintf(path, sizeof(path), “%s/%s.%s.so”,HAL_LIBRARY_PATH2, name, prop);if(access(path, R_OK) ==0) break;// 如果path指向有效庫檔案，退出for迴圈// 如果vendor/lib/hw目錄下沒有庫檔案，尋找/system/lib/hw目錄下有沒有：硬體id名.prop.so的庫檔案snprintf(path, sizeof(path), “%s/%s.%s.so”,HAL_LIBRARY_PATH1, name, prop);If(access(path, R_OK) == 0) break;} else {// 如果4個系統屬性都沒有定義，則使用預設的庫名：/system/lib/hw/硬體id名.default.sosnprintf(path, sizeof(path), “%s/%s.default.so”,HAL_LIBRARY_PATH1, name);If(access(path, R_OK) == 0) break;}}status = -ENOENT;if(i<HAL_VARIANT_KEYS_COUNT+1){status = load(class_id, path, module);// 難道是要載入前面尋找到的so庫？？}return status;}static int load(const char *id, counst char *path, const struct hw_module_t **pHmi){void *handle;struct hw_module_t * hmi;// 通過dlopen開啟so庫handle = dlopen(path, RTLD_NOW);// sym的值為”HMI”，這個名字還有印象嗎？const char * sym = HAL_MODULE_INFO_SYM_AS_STR;// 通過dlsym從開啟的庫裡尋找”HMI”這個符號，如果在so代碼裡有定義的函數名或變數名為HMI，dlsym返回其地址hmi，將該地址轉化成hw_module_t類型，即，硬體對象，這招夠狠，“殺雞取卵”hmi = (struct hw_module_t *)dlsym(handle, sym);// 判斷找到的硬體對象的id是否和要尋找的id名一致，不一致出錯退出// 取了卵還要驗證下是不是自己要的“卵”if(strcmp(id, hmi->) != 0){// 出錯退出處理}// 將庫的控制代碼儲存到hmi硬體對象的dso成員裡hmi->dso = handle;// 將硬體對象地址送給load函數者，最終將硬體對象返回到了hw_get_module的調用者*pHmi = hmi;// 成功返回}

通過上面代碼的注釋分析可知，硬體對象聲明的結構體代碼被編譯成了so庫，由於該結構體聲明為const類型，被so庫包含在其靜態程式碼片段裡，要找到硬體對象，首先要找到其對應的so庫，再通過dlopen，dlsym這種“殺雞取卵”的方式找到硬體對象，當然這兒的：“雞”是指：so庫，“卵”既：硬體對象led_module_t結構。

在聲明結構體led_module_t時，其名字統一定義為了HMI，而這麼做的目的就是為了通過dlsym來尋找led HAL Stub源碼產生的so庫裡的”HMI”符號。現在很明顯了，我們寫的HAL Stub代碼最終要編譯so庫檔案，並且庫檔案名稱為：led.default.so（當然可以設定四個系統屬性之一來指定名字為：led.屬性值.so），並且庫的所在目錄為：/system/lib/hw/。

現在底層的實現部分基本上吃透了，現在我們把目光放到調用者上，根據本章開頭介紹可知，上層調用本地代碼要使用JNI技術，我們先來惡補下JNI的知識吧。