ITdaan
中文简体   相关内容

HAL/JNI簡明筆記（一）——HAL基本框架

本文转载自  Jerry_xianrui  查看原文  2018-02-07  14    HAL/ 笔记/ jni/ android/ stub/ 硬件抽象层/ 框架           

原文博客地址：http://blog.csdn.net/sgmenghuo/article/details/44563765


環境：

android 4.3


HAL(hardware abstract layer)是位於操作系統與硬件之間的接口層，目的在於硬件抽象化。它存在於linux的應用層，它在Android系統中的位置是：向下連接驅動，向上給JNI提供接口。

源碼的位置：

msm8x12\hardware\libhardware_legacy 為過去的HAL目錄，采用鏈接庫模塊概念的舊架構，audio,power,wifi,vibrator,uevent等有使用該架構

X:\D500_android\msm8x12\hardware\libhardware 為當前使用的HAL架構，audio,bluetooth,camera,fb,gps,lights,power,sensor,rtc,nfc等有使用該架構

兩種HAL架構示意圖如下：


其中左邊的HAL架構繼承的是老的linux共享庫思路，把硬件接口都打包到libhardware_legacy.so，Android的JNI在要調用到這個庫的硬件接口函數時，只要將Android.mk中的LOCAL_SHARED_LIBRARIES增加libhardware_legacy就行，這樣就會到共享庫中獲取接口。

缺點：多個進程使用時，會映射到多個進程空間，造成浪費。

右邊的HAL架構是當前Android源碼中使用的思路，每一個硬件模塊稱為一個stub（代理人），並且借屍so的形式編譯，所有的stub都要通過libhardware.so(由hardware.c)才能找到每一個stub，才能回調每一個stub中硬件抽象接口，當然stub在編寫時需要按照HAL_MODULE_INFO_SYM的格式來寫，通過libhardware.so找到stub時，就會將該stub加載到內存，返回該stub的模塊指針。

優點：采用HAL module和HAL stub結合形式，HAL stub不是共享庫，上層只擁有訪問stub的函數指針，並不需要stub，Runtime只需要根據module ID並通過HAL module提供的統一接口就能取得stub的操作函數，只會被映射到一個進程，不會浪費空間。


對於libhardware.so/hardware.c而言，我們只需關心它里面幾個重要的結構體和一些路徑和命名規則即可。

比較重要的結構體代碼片如下：

[cpp] view plain copy
print ?
  1. / 
  2.   Every device data structure must begin with hw_device_t 
  3.   followed by module specific public methods and attributes. 
  4.   每個設備結構體成員都要以hw_device_t開頭，然后再是設備專有其他屬性方法 
  5.  /  
  6. typedef struct hw_device_t {  
  7.     / tag must be initialized to HARDWARE_DEVICE_TAG /  
  8.     uint32_t tag;  
  9.   
  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 ,一般是回收device結構體/  
  19.     int (close)(struct hw_device_t device);  
  20.   
  21. } hw_device_t;  
  22.   
  23. / 
  24.   每個模塊stub結構體變量必須命名為HAL_MODULE_INFO_SYM，數據域成員必須以 
  25.   hw_module_t開頭，然后再是模塊專有屬性方法 
  26.  /  
  27. typedef struct hw_module_t {  
  28.     / tag must be initialized to HARDWARE_MODULE_TAG /  
  29.     uint32_t tag;  
  30.   
  31.     uint16_t module_api_version;  
  32. #define version_major module_api_version  
  33.     / 
  34.       Presently, 0 is the only valid value. 
  35.       當前必須賦值為0 
  36.      /  
  37.     uint16_t hal_api_version;  
  38. #define version_minor hal_api_version  
  39.   
  40.     / 模塊的module ID /  
  41.     const char id;  
  42.   
  43.     / Name of this module /  
  44.     const char name;  
  45.   
  46.     / Author/owner/implementor of the module /  
  47.     const char author;  
  48.   
  49.     / Modules methods /  
  50.     struct hw_module_methods_t* methods;  
  51.   
  52.     / module’s dso /  
  53.     void dso;  
  54.   
  55.     / padding to 128 bytes, reserved for future use /  
  56.     uint32_t reserved[32-7];  
  57.   
  58. } hw_module_t;  
  59.   
  60.   
  61. typedef struct hw_module_methods_t {  
  62.     / Open a specific device ，基本就是malloc設備結構體，並加上回調函數接口/  
  63.     int (open)(const struct hw_module_t module, const char id,  
  64.             struct hw_device_t device);  
  65.   
  66. } hw_module_methods_t;  
/* 
 * Every device data structure must begin with hw_device_t 
 * followed by module specific public methods and attributes. 
 * 每個設備結構體成員都要以hw_device_t開頭，然后再是設備專有其他屬性方法 
 */ 
typedef struct hw_device_t { 
    /* tag must be initialized to HARDWARE_DEVICE_TAG / 
    uint32_t tag;

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 ,一般是回收device結構體*/
int (*close)(struct hw_device_t* device);

} hw_device_t;

/**
* 每個模塊stub結構體變量必須命名為HAL_MODULE_INFO_SYM，數據域成員必須以
* hw_module_t開頭，然后再是模塊專有屬性方法
*/
typedef struct hw_module_t {
/* tag must be initialized to HARDWARE_MODULE_TAG /
uint32_t tag;

uint16_t module_api_version;
#define version_major module_api_version /** * Presently, 0 is the only valid value. * 當前必須賦值為0 */ uint16_t hal_api_version;#define version_minor hal_api_version /** 模塊的module ID */ const char *id; /** 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;typedef struct hw_module_methods_t { /** Open a specific device ，基本就是malloc設備結構體，並加上回調函數接口*/ int (*open)(const struct hw_module_t* module, const char* id, struct hw_device_t** device);} hw_module_methods_t;


下面以名為ctp的 HAL stub為例，給出結構圖來解釋這些結構體之間的關系：



另外libhardware.so搜索stub的路徑優先順序為：先搜索/vendor/lib/hw目錄，再搜索/system/lib/hw；

在每個路徑下搜索stub的命名優先順序為(其中name為定義的module ID，后一個參數為屬性值):

<MODULE_ID>.$(ro.product.board).so例如led.trout.so

<MODULE_ID>.$(ro.board.platform).so例如led.msm7k.so

<MODULE_ID>.$(ro.arch).so例如led.ARMV6.so

若以上都未搜索到stub，那么就搜索/system/lib/hw/<MODULE_ID>.default.so


新框架總的思路：


具體來說：android frameworks中JNI調用/hardware/libhardware/hardware.c中定義的hw_get_module函數來獲取硬件模塊，然后調用硬件模塊中的方法，硬件模塊中的方法直接調用內核接口完成相關功能。


其中每一個module/stub的定義時都叫做HAL_MODULE_INFO_SYM，那么當系統中存在兩個或者更多個使用了相同HAL Module Name的so的時候，不就混亂了么？

帶着這個疑問查看 Android 源碼，會發現 Android 中實現調用 HAL 是通過 hw_get_module 實現的。

int hw_get_module(const char *id, const struct hw_module_t **module);

這是其函數原型， id 會指定 Hardware 的 id ，這是一個字符串，比如 sensor 的 id 是

#define SENSORS_HARDWARE_MODULE_ID “sensors” ，如果找到了對應的 hw_module_t 結構體，會將其指針放入 *module 中。看看它的實現。。。。

    /* Loop through the configuration variants looking for a module */

    for (i=0 ; i<HAL_VARIANT_KEYS_COUNT+1 ; i++) {

        if (i < HAL_VARIANT_KEYS_COUNT) {

             // 獲取 ro.hardware/ro.product.board/ro.board.platform/ro.arch 等 key 的值。

            if (property_get(variant_keys[i], prop, NULL) == 0) {

                continue;

            }

            snprintf(path, sizeof(path), “%s/%s.%s.so”,

                    HAL_LIBRARY_PATH, id, prop);

              // 如果開發板叫做 mmdroid, 那么這里的 path 就是system/lib/hw/sensor.mmdroid.so

        } else {

            snprintf(path, sizeof(path), “%s/%s.default.so”,

                    HAL_LIBRARY_PATH, id);// 默認會加載 /system/lib/hw/sensor.default.so

 

         }

        if (access(path, R_OK)) {

            continue;

        }

        /* we found a library matching this id/variant */

        break;

    }

    status = -ENOENT;

    if (i < HAL_VARIANT_KEYS_COUNT+1) {

        /* load the module, if this fails, we’re doomed, and we should not try

         * to load a different variant. */

        status = load(id, path, module);// 調用 load 函數打開動態鏈接庫

    }

 

 

獲取了動態鏈接庫的路徑之后，就會調用 load 函數打開它，下面會打開它。

 

奧秘在 load 中

static int load(const char *id,

        const char *path,

        const struct hw_module_t **pHmi)

{

    int status;

    void *handle;

    struct hw_module_t *hmi;

 

    /*

     * load the symbols resolving undefined symbols before

     * dlopen returns. Since RTLD_GLOBAL is not or’d in with

     * RTLD_NOW the external symbols will not be global

     */

    handle = dlopen(path, RTLD_NOW);// 打開動態庫

    if (handle == NULL) {

        char const *err_str = dlerror();

        LOGE(“load: module=%s/n%s”, path, err_str?err_str:”unknown”);

        status = -EINVAL;

        goto done;

    }

 

    /* Get the address of the struct hal_module_info. */

    const char *sym = HAL_MODULE_INFO_SYM_AS_STR;// 被定義為了“ HMI ”

    hmi = (struct hw_module_t *)dlsym(handle, sym);// 查找“ HMI ”這個導出符號，並獲取其地址

    if (hmi == NULL) {

        LOGE(“load: couldn’t find symbol %s”, sym);

        status = -EINVAL;

        goto done;

    }

 

/* Check that the id matches */

// 找到了 hw_module_t 結構！！！

    if (strcmp(id, hmi->id) != 0) {

        LOGE(“load: id=%s != hmi->id=%s”, id, hmi->id);

        status = -EINVAL;

        goto done;

    }

 

    hmi->dso = handle;

 

    /* success */

    status = 0;

 

    done:

    if (status != 0) {

        hmi = NULL;

        if (handle != NULL) {

            dlclose(handle);

            handle = NULL;

        }

    } else {

        LOGV(“loaded HAL id=%s path=%s hmi=%p handle=%p”,

                id, path, *pHmi, handle);

    }

  // 凱旋而歸

    *pHmi = hmi;

 

     return status;

}

從上面的代碼中，會發現一個很奇怪的宏 HAL_MODULE_INFO_SYM_AS_STR ，它直接被定義為了 #define HAL_MODULE_INFO_SYM_AS_STR  “HMI” ，為何根據它就能從動態鏈接庫中找到這個 hw_module_t 結構體呢？我們查看一下我們用到的 hal 對應的 so 就可以了，在 linux 中可以使用 readelf XX.so –s 查看。

Symbol table ‘.dynsym’ contains 28 entries:

   Num:     Value  Size Type    Bind   Vis      Ndx Name

     0: 00000000     0 NOTYPE  LOCAL  DEFAULT  UND

     1: 00000594     0 SECTION LOCAL  DEFAULT    7

     2: 00001104     0 SECTION LOCAL  DEFAULT   13

     3: 00000000     0 FUNC    GLOBAL DEFAULT  UND ioctl

     4: 00000000     0 FUNC    GLOBAL DEFAULT  UND strerror

     5: 00000b84     0 NOTYPE  GLOBAL DEFAULT  ABS __exidx_end

     6: 00000000     0 OBJECT  GLOBAL DEFAULT  UND __stack_chk_guard

     7: 00000000     0 FUNC    GLOBAL DEFAULT  UND __aeabi_unwind_cpp_pr0

     8: 00000000     0 FUNC    GLOBAL DEFAULT  UND __errno

     9: 00001188     0 NOTYPE  GLOBAL DEFAULT  ABS _bss_end__

    10: 00000000     0 FUNC    GLOBAL DEFAULT  UND malloc

    11: 00001188     0 NOTYPE  GLOBAL DEFAULT  ABS __bss_start__

    12: 00000000     0 FUNC    GLOBAL DEFAULT  UND __android_log_print

    13: 00000b3a     0 NOTYPE  GLOBAL DEFAULT  ABS __exidx_start

    14: 00000000     0 FUNC    GLOBAL DEFAULT  UND __stack_chk_fail

    15: 00001188     0 NOTYPE  GLOBAL DEFAULT  ABS __bss_end__

    16: 00001188     0 NOTYPE  GLOBAL DEFAULT  ABS __bss_start

    17: 00000000     0 FUNC    GLOBAL DEFAULT  UND memset

    18: 00000000     0 FUNC    GLOBAL DEFAULT  UND __aeabi_uidiv

    19: 00001188     0 NOTYPE  GLOBAL DEFAULT  ABS __end__

    20: 00001188     0 NOTYPE  GLOBAL DEFAULT  ABS _edata

    21: 00001188     0 NOTYPE  GLOBAL DEFAULT  ABS _end

    22: 00000000     0 FUNC    GLOBAL DEFAULT  UND open

    23: 00080000     0 NOTYPE  GLOBAL DEFAULT  ABS _stack

    24: 00001104   128 OBJECT  GLOBAL DEFAULT   13 HMI

    25: 00001104     0 NOTYPE  GLOBAL DEFAULT   13 __data_start

    26: 00000000     0 FUNC    GLOBAL DEFAULT  UND close

    27: 00000000     0 FUNC    GLOBAL DEFAULT  UND free

從上面中，第 24 個符號，名字就是“ HMI ”，對應於 hw_module_t 結構體。再去對照一下 HAL 的代碼。

/*

  * The COPYBIT Module

  */

struct copybit_module_t HAL_MODULE_INFO_SYM = {

    common: {

        tag: HARDWARE_MODULE_TAG,

        version_major: 1,

        version_minor: 0,

        id: COPYBIT_HARDWARE_MODULE_ID,

        name: “QCT MSM7K COPYBIT Module”,

        author: “Google, Inc.”,

        methods: &copybit_module_methods

    }

};

這里定義了一個名為 HAL_MODULE_INFO_SYM 的 copybit_module_t 的結構體， common 成員為hw_module_t 類型。注意這里的 HAL_MODULE_INFO_SYM 變量必須為這個名字，這樣編譯器才會將這個結構體的導出符號變為“ HMI ”，這樣這個結構體才能被 dlsym 函數找到！

綜上，我們知道了 andriod HAL 模塊也有一個通用的入口地址，這個入口地址就是 HAL_MODULE_INFO_SYM變量，通過它，我們可以訪問到 HAL 模塊中的所有想要外部訪問到的方法。


ref：Jerry_xianrui    Android HAL(硬件抽象層)介紹以及調用

                </div>

注意！

本站转载的文章为个人学习借鉴使用，本站对版权不负任何法律责任。如果侵犯了您的隐私权益，请联系我们删除。



HAL/JNI簡明筆記（一）——HAL基本框架 代碼示例_JNI / HAL 支付寶Sofa框架簡明筆記 《Android框架揭秘》讀書筆記——JNI Android HAL實現的三種方式(1) - 基於JNI的簡單HAL設計 安卓驅動、HAL、JNI與java HAL層開發框架介紹 tiny210 hal 4 Android系統中編寫JNI方法在應用程序框架層提供Java接口訪問硬件 簡明python教程筆記二 《簡明python教程》筆記二
 
粤ICP备14056181号  © 2014-2021 ITdaan.com