Android Hal层简要分析
生活随笔
收集整理的這篇文章主要介紹了
Android Hal层简要分析
小編覺得挺不錯的,現在分享給大家,幫大家做個參考.
Android Hal層簡要分析
/**? ?*每一個硬件都通過hw_module_t來描述，我們稱之為一個硬件對象。你可以去"繼承"這個hw_module_t? ?*然后擴展自己的屬性，硬件對象必須定義為一個固定的名字HMI,即:Hardware?Module?Information的簡寫? ?*每個硬件對象里都封裝了一個函數指針open用于打開硬件，我們理解為硬件對象的open方法，open調用后? ?*返回這個硬件對應的操作接口集合? ?*/?? typedef?struct?hw_module_t?{?? ????/**?tag?must?be?initialized?to?HARDWARE_MODULE_TAG?*/?? ????uint32_t?tag;????//該值必須聲明為HARDWARE_MODULE_TAG?? ?? ????/**? ?????*?The?API?version?of?the?implemented?module.?The?module?owner?is? ?????*?responsible?for?updating?the?version?when?a?module?interface?has? ?????*?changed.? ?????*? ?????*?The?derived?modules?such?as?gralloc?and?audio?own?and?manage?this?field.? ?????*?The?module?user?must?interpret?the?version?field?to?decide?whether?or? ?????*?not?to?inter-operate?with?the?supplied?module?implementation.? ?????*?For?example,?SurfaceFlinger?is?responsible?for?making?sure?that? ?????*?it?knows?how?to?manage?different?versions?of?the?gralloc-module?API,? ?????*?and?AudioFlinger?must?know?how?to?do?the?same?for?audio-module?API.? ?????*? ?????*?The?module?API?version?should?include?a?major?and?a?minor?component.? ?????*?For?example,?version?1.0?could?be?represented?as?0x0100.?This?format? ?????*?implies?that?versions?0x0100-0x01ff?are?all?API-compatible.? ?????*? ?????*?In?the?future,?libhardware?will?expose?a?hw_get_module_version()? ?????*?(or?equivalent)?function?that?will?take?minimum/maximum?supported? ?????*?versions?as?arguments?and?would?be?able?to?reject?modules?with? ?????*?versions?outside?of?the?supplied?range.? ?????*/?? ????uint16_t?module_api_version;?? #define?version_major?module_api_version?? ????/**? ?????*?version_major/version_minor?defines?are?supplied?here?for?temporary? ?????*?source?code?compatibility.?They?will?be?removed?in?the?next?version.? ?????*?ALL?clients?must?convert?to?the?new?version?format.? ?????*/?? ?? ????/**? ?????*?The?API?version?of?the?HAL?module?interface.?This?is?meant?to? ?????*?version?the?hw_module_t,?hw_module_methods_t,?and?hw_device_t? ?????*?structures?and?definitions.? ?????*? ?????*?The?HAL?interface?owns?this?field.?Module?users/implementations? ?????*?must?NOT?rely?on?this?value?for?version?information.? ?????*? ?????*?Presently,?0?is?the?only?valid?value.? ?????*/?? ????uint16_t?hal_api_version;?? #define?version_minor?hal_api_version?? ?? ????/**?Identifier?of?module?*/?? ????const?char?*id;?????//硬件id名，唯一標識module?? ?? ????/**?Name?of?this?module?*/?? ????const?char?*name;?????//硬件module的名字?? ?? ????/**?Author/owner/implementor?of?the?module?*/?? ????const?char?*author;?????//作者?? ?? ????/**?Modules?methods?*/?? ???//指向封裝有open函數指針的結構體?? ????struct?hw_module_methods_t*?methods;????? ?? ????/**?module's?dso?*/?? ????void*?dso;?? ?? ????/**?padding?to?128?bytes,?reserved?for?future?use?*/?? ????//128字節補齊?? ????uint32_t?reserved[32-7];?? ?? }?hw_module_t;?? ?? //硬件對象的open方法描述結構體，它里面只有一個元素:open函數指針?? typedef?struct?hw_module_methods_t?{?? ????/**?Open?a?specific?device?*/?? ????int?(*open)(const?struct?hw_module_t*?module,?const?char*?id,?? ????????????struct?hw_device_t**?device);?? ?? }?hw_module_methods_t;?? ?? /**? ?*?Every?device?data?structure?must?begin?with?hw_device_t? ?*?followed?by?module?specific?public?methods?and?attributes.? ?*/?? ?//硬件對象hw_module_t的open方法返回該硬件的Operation?interface，它由hw_device_t結構體來描述?? ?//我們稱之為該硬件的操作接口?? typedef?struct?hw_device_t?{?? ????/**?tag?must?be?initialized?to?HARDWARE_DEVICE_TAG?*/?? ????uint32_t?tag;????//必須賦值為HARDWARE_DEVICE_TAG?? ?? ????/**? ?????*?Version?of?the?module-specific?device?API.?This?value?is?used?by? ?????*?the?derived-module?user?to?manage?different?device?implementations.? ?????*? ?????*?The?module?user?is?responsible?for?checking?the?module_api_version? ?????*?and?device?version?fields?to?ensure?that?the?user?is?capable?of? ?????*?communicating?with?the?specific?module?implementation.? ?????*? ?????*?One?module?can?support?multiple?devices?with?different?versions.?This? ?????*?can?be?useful?when?a?device?interface?changes?in?an?incompatible?way? ?????*?but?it?is?still?necessary?to?support?older?implementations?at?the?same? ?????*?time.?One?such?example?is?the?Camera?2.0?API.? ?????*? ?????*?This?field?is?interpreted?by?the?module?user?and?is?ignored?by?the? ?????*?HAL?interface?itself.? ?????*/?? ????uint32_t?version;???//版本號?? ?? ????/**?reference?to?the?module?this?device?belongs?to?*/?? ????struct?hw_module_t*?module;??//該設備屬于哪個硬件對象，可以看成硬件操作接口與硬件對象的聯系?? ?? ????/**?padding?reserved?for?future?use?*/?? ????uint32_t?reserved[12];???//字節補齊?? ?? ????/**?Close?this?device?*/?? ????int?(*close)(struct?hw_device_t*?device);?//該設備的關閉函數指針?? ?? }?hw_device_t;?? /***每一個硬件都通過hw_module_t來描述，我們稱之為一個硬件對象。你可以去"繼承"這個hw_module_t*然后擴展自己的屬性，硬件對象必須定義為一個固定的名字HMI,即:Hardware Module Information的簡寫*每個硬件對象里都封裝了一個函數指針open用于打開硬件，我們理解為硬件對象的open方法，open調用后*返回這個硬件對應的操作接口集合*/
typedef struct hw_module_t {/** tag must be initialized to HARDWARE_MODULE_TAG */uint32_t tag; //該值必須聲明為HARDWARE_MODULE_TAG/*** The API version of the implemented module. The module owner is* responsible for updating the version when a module interface has* changed.** The derived modules such as gralloc and audio own and manage this field.* The module user must interpret the version field to decide whether or* not to inter-operate with the supplied module implementation.* For example, SurfaceFlinger is responsible for making sure that* it knows how to manage different versions of the gralloc-module API,* and AudioFlinger must know how to do the same for audio-module API.** The module API version should include a major and a minor component.* For example, version 1.0 could be represented as 0x0100. This format* implies that versions 0x0100-0x01ff are all API-compatible.** In the future, libhardware will expose a hw_get_module_version()* (or equivalent) function that will take minimum/maximum supported* versions as arguments and would be able to reject modules with* versions outside of the supplied range.*/uint16_t module_api_version;
#define version_major module_api_version/*** version_major/version_minor defines are supplied here for temporary* source code compatibility. They will be removed in the next version.* ALL clients must convert to the new version format.*//*** The API version of the HAL module interface. This is meant to* version the hw_module_t, hw_module_methods_t, and hw_device_t* structures and definitions.** The HAL interface owns this field. Module users/implementations* must NOT rely on this value for version information.** Presently, 0 is the only valid value.*/uint16_t hal_api_version;
#define version_minor hal_api_version/** Identifier of module */const char *id; //硬件id名，唯一標識module/** Name of this module */const char *name; //硬件module的名字/** Author/owner/implementor of the module */const char *author; //作者/** Modules methods *///指向封裝有open函數指針的結構體struct hw_module_methods_t* methods; /** module's dso */void* dso;/** padding to 128 bytes, reserved for future use *///128字節補齊uint32_t reserved[32-7];} hw_module_t;//硬件對象的open方法描述結構體，它里面只有一個元素:open函數指針
typedef struct hw_module_methods_t {/** Open a specific device */int (*open)(const struct hw_module_t* module, const char* id,struct hw_device_t** device);} hw_module_methods_t;/*** Every device data structure must begin with hw_device_t* followed by module specific public methods and attributes.*///硬件對象hw_module_t的open方法返回該硬件的Operation interface，它由hw_device_t結構體來描述//我們稱之為該硬件的操作接口
typedef struct hw_device_t {/** tag must be initialized to HARDWARE_DEVICE_TAG */uint32_t tag; //必須賦值為HARDWARE_DEVICE_TAG/*** Version of the module-specific device API. This value is used by* the derived-module user to manage different device implementations.** The module user is responsible for checking the module_api_version* and device version fields to ensure that the user is capable of* communicating with the specific module implementation.** One module can support multiple devices with different versions. This* can be useful when a device interface changes in an incompatible way* but it is still necessary to support older implementations at the same* time. One such example is the Camera 2.0 API.** This field is interpreted by the module user and is ignored by the* HAL interface itself.*/uint32_t version; //版本號/** reference to the module this device belongs to */struct hw_module_t* module; //該設備屬于哪個硬件對象，可以看成硬件操作接口與硬件對象的聯系/** padding reserved for future use */uint32_t reserved[12]; //字節補齊/** Close this device */int (*close)(struct hw_device_t* device); //該設備的關閉函數指針} hw_device_t;??? 上述三個結構體之間關系緊密，每個硬件對象都由hw_module_t來描述，只要我們拿到了這個硬件對象，就可以調用它的open方法，返回這個硬件對象的硬件操作接口，然后就可以通過這些硬件操作接口來間接操作硬件。只不過，open方法被hw_module_methods_t結構封裝了一次，硬件操作接口被hw_device_t封裝了一次而已。下面這張圖可以反映出它們三者的關系： //HAL?Stub對象固定的名字?? #define?HAL_MODULE_INFO_SYM?????????HMI?? ?? /**? ?*?Name?of?the?hal_module_info?as?a?string? ?*/?? ?? //字符串形式的名字?? #define?HAL_MODULE_INFO_SYM_AS_STR??"HMI"?? ?? /**? ?*?Get?the?module?info?associated?with?a?module?by?id.? ?*? ?*?@return:?0?==?success,?<0?==?error?and?*module?==?NULL? ?*/?? ?//通過硬件名來獲得硬件HAL?Stub對象?? int?hw_get_module(const?char?*id,?const?struct?hw_module_t?**module);?? //HAL Stub對象固定的名字
#define HAL_MODULE_INFO_SYM HMI/*** Name of the hal_module_info as a string*///字符串形式的名字
#define HAL_MODULE_INFO_SYM_AS_STR "HMI"/*** Get the module info associated with a module by id.** @return: 0 == success, <0 == error and *module == NULL*///通過硬件名來獲得硬件HAL Stub對象
int hw_get_module(const char *id, const struct hw_module_t **module);
用戶程序通過硬件的id名來拿到硬件，下面我們以android平臺下驅動的開發及測試框架概述（二）一文的例子來分析：struct?freg_module_t?HAL_MODULE_INFO_SYM?=?{???? ????common:?{???? ????????tag:?HARDWARE_MODULE_TAG,??????? ????????version_major:?1,???? ????????version_minor:?0,???? ????????id:?FREG_HARDWARE_MODULE_ID,???? ????????name:?MODULE_NAME,???? ????????author:?MODULE_AUTHOR,???? ????????methods:?&freg_module_methods,???? ????}???? ????//擴展屬性?? };???? struct freg_module_t HAL_MODULE_INFO_SYM = { common: { tag: HARDWARE_MODULE_TAG, version_major: 1, version_minor: 0, id: FREG_HARDWARE_MODULE_ID, name: MODULE_NAME, author: MODULE_AUTHOR, methods: &freg_module_methods, } //擴展屬性
}; 我們只需要聲明一個結構體freg_module_t，起名為HAL_MODULE_INFO_SYM，也就是固定的名字：HMI，然后將這個結構體填充好就行。 [cpp] view plaincopyprint? 而freg_module_t結構是“繼承”的hw_module_t類型，創建自己的硬件對象，然后擴展自己的特有屬性。?? ?? <pre?name="code"?class="cpp">struct?freg_module_t?{???? ????struct?hw_module_t?common;???? };???? 而freg_module_t結構是“繼承”的hw_module_t類型，創建自己的硬件對象，然后擴展自己的特有屬性。<pre name="code" class="cpp">struct freg_module_t { struct hw_module_t common;
};
上面的methods被初始化為freg_module_methods的地址，其結構為hw_methods_t類型的，其聲明代碼如下： [cpp] view plaincopyprint?static?struct?hw_module_methods_t?freg_module_methods?=?{???? ????open:?freg_device_open???? };???? static struct hw_module_methods_t freg_module_methods = { open: freg_device_open
}; 其僅有的open成員是個函數指針，它被指向freg_device_open函數：
[cpp] view plaincopyprint?static?int?freg_device_open(const?struct?hw_module_t*?module,?const?char*?id,?struct?hw_device_t**?device)?{???? ????if(!strcmp(id,?FREG_HARDWARE_DEVICE_ID))?{???? ????????struct?freg_device_t*?dev;???? ???? ????????dev?=?(struct?freg_device_t*)malloc(sizeof(struct?freg_device_t));???? ????????if(!dev)?{???? ????????????LOGE("Failed?to?alloc?space?for?freg_device_t.");???? ????????????return?-EFAULT;????? ????????}???? ???? ????????memset(dev,?0,?sizeof(struct?freg_device_t));???? ???? ????????dev->common.tag?=?HARDWARE_DEVICE_TAG;???? ????????dev->common.version?=?0;???? ????????dev->common.module?=?(hw_module_t*)module;???? ????????dev->common.close?=?freg_device_close;???? ????????dev->set_val?=?freg_set_val;???? ????????dev->get_val?=?freg_get_val;???? ???????? ????????if((dev->fd?=?open(DEVICE_NAME,?O_RDWR))?==?-1)?{???? ????????????LOGE("Failed?to?open?device?file?/dev/freg?--?%s.",?strerror(errno));???? ????????????free(dev);???? ????????????return?-EFAULT;???? ????????}???? ???? ????????*device?=?&(dev->common);???? ???? ????????LOGI("Open?device?file?/dev/freg?successfully.");??????? ???? ????????return?0;???? ????}???? ???? ????return?-EFAULT;???? }???? static int freg_device_open(const struct hw_module_t* module, const char* id, struct hw_device_t** device) { if(!strcmp(id, FREG_HARDWARE_DEVICE_ID)) { struct freg_device_t* dev; dev = (struct freg_device_t*)malloc(sizeof(struct freg_device_t)); if(!dev) { LOGE("Failed to alloc space for freg_device_t."); return -EFAULT; } memset(dev, 0, sizeof(struct freg_device_t)); dev->common.tag = HARDWARE_DEVICE_TAG; dev->common.version = 0; dev->common.module = (hw_module_t*)module; dev->common.close = freg_device_close; dev->set_val = freg_set_val; dev->get_val = freg_get_val; if((dev->fd = open(DEVICE_NAME, O_RDWR)) == -1) { LOGE("Failed to open device file /dev/freg -- %s.", strerror(errno)); free(dev); return -EFAULT; } *device = &(dev->common); LOGI("Open device file /dev/freg successfully."); return 0; } return -EFAULT;
} 這個open函數主要做了以下幾件事：
1：分配硬件設備操作結構體freg_device_t，其描述了硬件操作行為
2：初始化freg_device_t的父結構體hw_device_t成員
3：初始化了freg_device_t中的擴展的操作接口
4：打開設備，將freg_device_t結構體以父結構體類型返回
其中freg_device_t和父結構體hw_device_t的關系：
[cpp] view plaincopyprint?struct?freg_device_t?{???? ????struct?hw_device_t?common;???? ????int?fd;???? ????int?(*set_val)(struct?freg_device_t*?dev,?int?val);???? ????int?(*get_val)(struct?freg_device_t*?dev,?int*?val);???? };???? struct freg_device_t { struct hw_device_t common; int fd; int (*set_val)(struct freg_device_t* dev, int val); int (*get_val)(struct freg_device_t* dev, int* val);
}; 上面所涉及的擴展接口不再做進一步分析，其主要作用是直接和底層驅動打交道。
小結一下：static?const?char?*variant_keys[]?=?{???? ????“ro.hardware”,???? ????“ro.product.board”,???? ????“ro.board.platform”,???? ????“ro.arch”???? };???? //?由上面定義的字符串數組可知，HAL_VARIANT_KEYS_COUNT的值為4???? struct?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指針變量hmi???? ????const?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);???? ????else???? ????????strlcpy(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.so???? ????????????snprintf(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.so???? ????????????snprintf(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;???? ????//?成功返回???? }???? static const char *variant_keys[] = { “ro.hardware”, “ro.product.board”, “ro.board.platform”, “ro.arch” }; // 由上面定義的字符串數組可知，HAL_VARIANT_KEYS_COUNT的值為4 struct 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指針變量hmi const 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); else strlcpy(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.so snprintf(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.so snprintf(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; // 成功返回 }
????Android Hal層（即 Hardware Abstraction Layer）是Google開發的Android系統里上層應用對底層硬件操作屏蔽的一個軟件層次，說直白點，就是上層應用不必關心底層硬件具體是如何工作的，只需要調用底層提供的統一接口即可，這種設計思想廣泛的存在于當前的軟件的架構設計里。個人感覺，以前在Linux系統下學習驅動程序的開發時，當驅動程序完成時，我們會編寫相應的用戶空間測試程序，感覺這就有點類似此處的硬件抽象層的工作，只不過原來是把測試程序用交叉工具鏈編譯成可執行程序然后下載到開發板上進行驗證，而在Android的硬件抽象層中，將測試程序再進行了一次封裝，把測試接口封裝起來傳遞給上一層調用，這樣就能隱藏硬件的實現細節和參數。
????? 其實Android系統里完全可以沒有HAL硬件抽象層，上層應用可以直接通過API調用到底層硬件，但是Android自出現一直打著開源的旗號，而一些硬件設備廠商由于商業因素，不希望把自己的核心代碼開源出來，而只是提供二進制的代碼。另外，Android系統里使用的一些硬件設備接口可能不是使用的Linux Kernel的統一接口，并且還有GPL版權的原因，所以Google在Android架構里提出了Hal的概念，這個HAL其實就是獨立的意思，Android系統不僅依賴于某一個具體的硬件驅動，而是依賴于Hal代碼，這樣，第三方廠商可以將自己不開源的代碼封裝在HAL層，僅僅提供二進制代碼。在具體分析Android硬件抽象層之前，先從下圖了解下其在整個Android系統架構中所處的位置：
Android Hal架構分為兩種：
①舊的架構module
②新的架構module stub
下面我們就具體分析下兩種架構各自的特點：
一 Module架構
???? Android用戶應用程序或者框架層代碼由JAVA實現，Java運行在Dalvik虛擬機中，沒有辦法直接訪問底層硬件，只能通過調用so本地庫代碼實現，在so本地代碼里有對底層硬件操作的代碼，如下圖所示：
?????? 可以這樣說，應用層或者框架層Java代碼，通過JNI技術調用C或C++寫的so庫代碼，在so庫代碼中調用底層驅動，從而實現上層應用操作底層硬件的目的。實現硬件操作的so庫為module.
其實現流程如下圖所示：
?????? 這種設計架構雖然滿足了Java應用訪問硬件的需要，但是，使得我們的代碼上下層次間的耦合太高，用戶程序或者框架代碼必須要去加載module庫，如果底層硬件有變化，module要從新編譯，上層也要做相應變化，另外，如果多個應用程序同時訪問硬件，都去加載module，同一module被多個進程映射多次，會有代碼的重入問題。
二 新的Hal架構：
???? 新的代碼架構使用的是module stub方式.Stub是存根或者樁的意思，其實說白了，就是指一個對象代表的意思。上層應用層或者框架層代碼加載so庫代碼，so庫代碼我們稱之為module，在Hal層注冊了每個硬件對象的存根stub，當上層需要訪問硬件的時候，就從當前注冊的硬件對象stub里查找，找到之后stub會向上層module提供該硬件對象的operations interface（操作接口），該操作接口就保存在module中，上層應用或框架層再通過這個module操作接口來訪問硬件。其架構如下：
以上分別介紹了Module架構和Stub架構，下面做一個對比：
? 在Module架構中，本地代碼由so庫實現，上層直接將so庫映射到進程空間，會有代碼重入及設備多次打開的問題。新的Stub框架雖然也要加載module庫，但是這個module已經不包含操作底層硬件驅動的功能了，它里面保存的只是底層stub提供的操作接口，底層stub扮演了“接口提供者”的角色，當stub第一次被使用時加載到內存，后續再使用時僅返回硬件對象操作接口，不會存在設備多次打開的問題，并且由于多進程訪問時返回的只是函數指針，代碼并沒有重入。
三 Hal Stub框架分析
???? Hal Stub的框架比較簡單，三個結構體、兩個常量、一個函數，簡稱321架構，它的定義在：
???? alps/hardware/libhardware/include/hardware/hardware.h
????? alps/hardware/libhardware/hardware.c
下面我們先看下三個重要的結構體，其包含在hardware.h中：
[cpp] view plaincopyprint?
接下來在看321架構中的:兩個符號常量和一個函數：
[cpp] view plaincopyprint?用戶程序通過硬件的id名來拿到硬件，下面我們以android平臺下驅動的開發及測試框架概述（二）一文的例子來分析：
注冊一個硬件對象的方法其實只需要聲明一個結構體即可，以注冊freg_module_t為例：
[cpp] view plaincopyprint?上面的methods被初始化為freg_module_methods的地址，其結構為hw_methods_t類型的，其聲明代碼如下： [cpp] view plaincopyprint?
[cpp] view plaincopyprint?
1：分配硬件設備操作結構體freg_device_t，其描述了硬件操作行為
2：初始化freg_device_t的父結構體hw_device_t成員
3：初始化了freg_device_t中的擴展的操作接口
4：打開設備，將freg_device_t結構體以父結構體類型返回
其中freg_device_t和父結構體hw_device_t的關系：
[cpp] view plaincopyprint?
小結一下：
???? 我們有一個硬件id名，通過這個id調用hw_get_module(const char *id, const struct hw_module_t **module)這個函數查找注冊到當前系統中與id對應的硬件對象并返回，硬件對象里有個通過hw_module_methods_t結構體封裝的open函數指針，回調這個open函數，它返回封裝有硬件操作接口的freg_device_t結構體，這樣我們就可以通過這個硬件接口去間接訪問硬件了。可以用下面的圖來描述這個過程：
下面我們再來看hw_get_module這個函數的具體實現，其實現在hardware.c中：
[cpp] view plaincopyprint??????? 通過上面代碼的注釋分析可知，硬件對象聲明的結構體代碼被編譯成了so庫，由于該結構體聲明為const類型，被so庫包含在其靜態代碼段里，要找到硬件對象，首先要找到其對應的so庫，再通過dlopen，dlsym這種“殺雞取卵”的方式找到硬件對象，當然這兒的：“雞”是指：so庫，“卵”即硬件對象led_module_t結構。
????? 在聲明結構體freg_module_t時，其名字統一定義為了HMI，而這么做的目的就是為了通過dlsym來查找Freg HAL Stub源碼生成的so庫里的”HMI”符號。現在很明顯了，我們寫的HAL Stub代碼最終要編譯so庫文件，并且庫文件名為：freg.default.so（當然可以設置四個系統屬性之一來指定名字為：freg.屬性值.so），并且庫的所在目錄為：/system/lib/hw/。
Android Hal層簡要分析大致都這樣了。
參考博文：http://blog.csdn.net/mr_raptor/article/details/8074549
總結
以上是生活随笔為你收集整理的Android Hal层简要分析的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 基于MT6752/32平台 Androi
- 下一篇： wince6.0 编译报错:error