Google為了保護硬體廠商的資訊，在Android中添加了一層，它就是大名鼎鼎的HAL層。

在看HAL的編寫方法的過程中，會發現整個模組貌似沒有一個入口。一般說來模組都要有個入口，比如應用程式的main函式，可以被載入器進行載入執行，dll檔案有dllmain，而對於我們自己寫的動態連結庫，我們可以對庫中匯出的任何符號進行呼叫。

那麼問題來了，Android中的HAL是具有通用性的，需要上層的函式對其進行載入呼叫，Android的HAL載入器是如何實現對不同的Hardware Module進行通用性的呼叫的呢？我們今天將以Sensor hal模組的載入為例，剖析下hal層的具體呼叫邏輯。

SensorService啟動

在看Sensor架構的時候，SensorService服務啟動後，在隨後的第一次初始化時，其onFirstRef會被呼叫（均繼承自RefBase虛基類），緊接著，它會獲取我們的SensorDevice例項:

void SensorService::onFirstRef()
{
    ALOGD("nuSensorService starting...");
    SensorDevice& dev(SensorDevice::getInstance());

    if (dev.initCheck() == NO_ERROR) {
        sensor_t const* list;
        ssize_t count = dev.getSensorList(&list);
 

附上這部分的流程

SensorDevice作為Sensor架構中native的最後一個檔案，與Hal層進行通訊，故而在SensorDevice的構造方法中，我們就可以看到著名的hw_get_module和Sensor_Open方法了：

SensorDevice::SensorDevice()
    :  mSensorDevice(0),
       mSensorModule(0)
{
    status_t err = hw_get_module(SENSORS_HARDWARE_MODULE_ID,
            (hw_module_t const**)&mSensorModule);

    ALOGE_IF(err, "couldn't load %s module (%s)",
            SENSORS_HARDWARE_MODULE_ID, strerror(-err));

    if (mSensorModule) {
        err = sensors_open_1(&mSensorModule->common, &mSensorDevice);

        ALOGE_IF(err, "couldn't open device for module %s (%s)",
                SENSORS_HARDWARE_MODULE_ID, strerror(-err));

        if (mSensorDevice) {
            if (mSensorDevice->common.version == SENSORS_DEVICE_API_VERSION_1_1 ||
                mSensorDevice->common.version == SENSORS_DEVICE_API_VERSION_1_2) {
                ALOGE(">>>> WARNING <<< Upgrade sensor HAL to version 1_3");
            }

            sensor_t const* list;
            ssize_t count = mSensorModule->get_sensors_list(mSensorModule, &list);
            mActivationCount.setCapacity(count);
            Info model;
            for (size_t i=0 ; i<size_t(count) ; i++) {
                mActivationCount.add(list[i].handle, model);
                mSensorDevice->activate(
                        reinterpret_cast<struct sensors_poll_device_t *>(mSensorDevice),
                        list[i].handle, 0);
            }
        }
    }
}
 

其中SENSORS_HARDWARE_MODULE_ID是在hardware/sensors.h中定義的module名字：

/**
 * The id of this module
 */
#define SENSORS_HARDWARE_MODULE_ID "sensors"

而mSensorModule就是我們的sensors_module_t結構體，這些都是在hal層sensors.h中定義的：

struct sensors_module_t {
    struct hw_module_t common;

    /**
     * Enumerate all available sensors. The list is returned in "list".
     * @return number of sensors in the list
     */
    int (*get_sensors_list)(struct sensors_module_t* module,
            struct sensor_t const** list);

    /**
     *  Place the module in a specific mode. The following modes are defined
     *
     *  0 - Normal operation. Default state of the module.
     *  1 - Loopback mode. Data is injected for the the supported
     *      sensors by the sensor service in this mode.
     * @return 0 on success
     *         -EINVAL if requested mode is not supported
     *         -EPERM if operation is not allowed
     */
    int (*set_operation_mode)(unsigned int mode);
};

可以看到sensors_module_t結構體擴充套件了hw_module_t，他裡面額外提供了get_sensor_list方法來獲取系統支援的sensor列表以及一個模式設定方法。

接下來，我們跟進hw_get_module方法，看看它到底做了什麼？

hw_get_module

該函式具體實現在hardware/libhardware/hardware.c中

int hw_get_module(const char *id, const struct hw_module_t **module)
{
    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 i = 0;
    char prop[PATH_MAX] = {0};
    char path[PATH_MAX] = {0};
    char name[PATH_MAX] = {0};
    char prop_name[PATH_MAX] = {0};


    if (inst)
        snprintf(name, PATH_MAX, "%s.%s", class_id, inst);
    else
        strlcpy(name, class_id, PATH_MAX);

    /*
     * Here we rely on the fact that calling dlopen multiple times on
     * the same .so will simply increment a refcount (and not load
     * a new copy of the library).
     * We also assume that dlopen() is thread-safe.
     */

    /* First try a property specific to the class and possibly instance */
    snprintf(prop_name, sizeof(prop_name), "ro.hardware.%s", name);
    if (property_get(prop_name, prop, NULL) > 0) {
        if (hw_module_exists(path, sizeof(path), name, prop) == 0) {
            goto found;
        }
    }

    /* Loop through the configuration variants looking for a module */
    for (i=0 ; i<HAL_VARIANT_KEYS_COUNT; i++) {
        if (property_get(variant_keys[i], prop, NULL) == 0) {
            continue;
        }
        if (hw_module_exists(path, sizeof(path), name, prop) == 0) {
            goto found;
        }
    }

    /* Nothing found, try the default */
    if (hw_module_exists(path, sizeof(path), name, "default") == 0) {
        goto found;
    }

    return -ENOENT;

found:
    /* load the module, if this fails, we're doomed, and we should not try
     * to load a different variant. */
    return load(class_id, path, module);
}

我們主要看hw_get_module_by_class，這裡傳入的引數分別是“sensors”，null，以及我們的mSensorModule結構體。

首先將字串拷貝給name：

strlcpy(name, class_id, PATH_MAX);

接著拼接prop_name為ro.hardware.name，即prop_name=ro.hardware.sensors

通過property_get方法並沒有得到這個值的定義(因為在系統中並沒有對其定義)，所以接下來會進入下面的迴圈：

for (i=0 ; i<HAL_VARIANT_KEYS_COUNT; i++) {
        if (property_get(variant_keys[i], prop, NULL) == 0) {
            continue;
        }
        if (hw_module_exists(path, sizeof(path), name, prop) == 0) {
            goto found;
        }
    }

/**
 * 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"
};

根據上面的解析我門也可以看到，將會分別查詢sensors.variant.so，sensors.product.so，sensors.platform.so，以及sensors.default.so，最終我們會在/system/lib/hw/路徑下找到sensors.msm8952.so，然後將其通過load方法載入進記憶體中執行。由此也可知，我分析的是高通8952平臺。

小細節：當我們實現了自己的HAL層module，並且寫了一個應用程式測試module是否正常工作，那麼在編譯的時候，下面的引數應該要這樣寫：

LOCAL_MODULE := moduleName.default

或者

LOCAL_MODULE := moduleName.$(TARGET_BOARD_PLATFORM)

由於上面原始碼的原因，如果module名字對應不到，你的這個模組將不會被正常的load進去，因而也就無法正常工作了。

接著我們分析load的實現。

static int load(const char *id,
        const char *path,
        const struct hw_module_t **pHmi)
{
    int status = -EINVAL;
    void *handle = NULL;
    struct hw_module_t *hmi = NULL;

    /*
     * 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();
        ALOGE("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 = (struct hw_module_t *)dlsym(handle, sym);
    if (hmi == NULL) {
        ALOGE("load: couldn't find symbol %s", sym);
        status = -EINVAL;
        goto done;
    }

    /* Check that the id matches */
    if (strcmp(id, hmi->id) != 0) {
        ALOGE("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 {
        ALOGV("loaded HAL id=%s path=%s hmi=%p handle=%p",
                id, path, *pHmi, handle);
    }

    *pHmi = hmi;

    return status;
}

1. 首先通過dlopen開啟sensors.xxx.so模組，獲得其控制代碼handle

2.呼叫dlsym去獲取結構體hw_module_t結構體的地址，注意這裡傳入的字串為HAL_MODULE_INFO_SYM_AS_STR，定義在hardware.h標頭檔案中

/**
 * Name of the hal_module_info
 */
#define HAL_MODULE_INFO_SYM         HMI

/**
 * Name of the hal_module_info as a string
 */
#define HAL_MODULE_INFO_SYM_AS_STR  "HMI"

這裡為什麼要去取名字為HMI的地址，我猜想它應該是HAL模組的入口了。

課外知識—ELF檔案格式：

ELF = Executable and Linkable Format，可執行連線格式，是UNIX系統實驗室（USL）作為應用程式二進位制介面（Application Binary Interface，ABI）而開發和釋出的，副檔名為elf。一個ELF頭在檔案的開始，儲存了路線圖(road map)，描述了該檔案的組織情況。sections儲存著object 檔案的資訊，從連線角度看：包括指令，資料,符號表，重定位資訊等等。通過file命令我們可知sensors.xx.so是一個ELF檔案格式

[email protected]:~$ file sensors.msm8952.so
sensors.msm8952.so: ELF 32-bit LSB shared object, ARM, version 1 (SYSV), dynamically linked (uses shared libs), BuildID[md5/uuid]=0x25812b01ab4700281b41f61327075611, not stripped

因此，通過linux的readelf命令我們可以檢視該檔案的內部佈局及符號表等資訊。

[email protected]:~$ readelf -s sensors.msm8952.so

Symbol table '.dynsym' contains 157 entries:
   Num:    Value  Size Type    Bind   Vis      Ndx Name
     0: 00000000     0 NOTYPE  LOCAL  DEFAULT  UND
     1: 00000000     0 FUNC    GLOBAL DEFAULT  UND [email protected] (2)
     2: 00000000     0 FUNC    GLOBAL DEFAULT  UND [email protected] (2)
     3: 00000000     0 FUNC    GLOBAL DEFAULT  UND [email protected] (2)
     4: 00000000     0 FUNC    GLOBAL DEFAULT  UND [email protected] (2)
        …………………………// 省略無關資訊
   108: 00006d5c    16 FUNC    WEAK   DEFAULT   13 __aeabi_ldiv0
   109: 000042d5    14 FUNC    WEAK   DEFAULT   13 _ZNSt3__13mapIi10FullHand
   110: 000053d7    12 FUNC    WEAK   DEFAULT   13 _ZTv0_n12_NSt3__114basic_
   111: 0000a0cd     0 NOTYPE  GLOBAL DEFAULT  ABS _end
   112: 000054b1    40 FUNC    GLOBAL DEFAULT   13 _ZN16SensorEventQueue7deq
   113: 0000a00c   136 OBJECT  GLOBAL DEFAULT   23 HMI
   114: 000053eb    52 FUNC    GLOBAL DEFAULT   13 _ZN16SensorEventQueueC1Ei
   115: 00006d5c    16 FUNC    WEAK   DEFAULT   13 __aeabi_idiv0
   116: 00003879    14 FUNC    WEAK   DEFAULT   13 _ZNSt3__115basic_streambu
   117: 00003c75    76 FUNC    WEAK   DEFAULT   13 _ZNSt3__113basic_filebufI
   118: 0000a098    12 OBJECT  GLOBAL DEFAULT   24 full_to_global

由符號表可知，HMI的地址為000a00c，拿到函式地址，當然就可以執行對應的程式碼了。

QualComm Sensor HAL

因此我們接著看sensor_hal層，高通的Sensor實現了自己的HAL，其原始碼在vendor/qcom/proprietary/sensors/dsps/libhalsensors路徑下，通過Android.mk我們也可以確定他確實是我們前面load方法開啟的動態連結庫,其編譯後會生成sensor.msm8952.so：

# vendor/qcom/proprietary/sensors/dsps/libhalsensors/Android.mk
ifeq ($(USE_SENSOR_MULTI_HAL),true)
LOCAL_MODULE := sensors.ssc
LOCAL_CLANG := false
else
LOCAL_MODULE := sensors.$(TARGET_BOARD_PLATFORM)
LOCAL_MODULE_RELATIVE_PATH := hw
endif

那麼HMI的入口到底定義在這裡的那個檔案中呢？ 

功夫不負有心人，在sensors_hal.cpp中，我們終於找到了HMI的入口，即下面的結構體：

static struct hw_module_methods_t sensors_module_methods = {
    .open = sensors_open
};

struct sensors_module_t HAL_MODULE_INFO_SYM = {
    .common = {
        .tag = HARDWARE_MODULE_TAG,
        .module_api_version = (uint16_t)SENSORS_DEVICE_API_VERSION_1_3,
        .hal_api_version = HARDWARE_HAL_API_VERSION,
        .id = SENSORS_HARDWARE_MODULE_ID,
        .name = "QTI Sensors Module",
        .author = "Qualcomm Technologies, Inc.",
        .methods = &sensors_module_methods,
        .dso = NULL,
        .reserved = {0},
    },
    .get_sensors_list = sensors_get_sensors_list,
    .set_operation_mode = sensors_set_operation_mode
};

HAL_MODULE_INFO_SYM即上文提到的HMI變數，恭喜各位，這裡我們就開啟了QualComm Sensor HAL的大門。

最後這個hw_module_t的結構體控制代碼會返回給我們的SensorDevice的建構函式裡：

SensorDevice::SensorDevice()
    :  mSensorDevice(0),
       mSensorModule(0)
{
    status_t err = hw_get_module(SENSORS_HARDWARE_MODULE_ID,
            (hw_module_t const**)&mSensorModule);

    ALOGE_IF(err, "couldn't load %s module (%s)",
            SENSORS_HARDWARE_MODULE_ID, strerror(-err));

    if (mSensorModule) {
        err = sensors_open_1(&mSensorModule->common, &mSensorDevice);

接著，通過sensors_open_1方法將module->common傳入，開啟我們的sensor驅動。

// hardware/libhardware/include/hardware/sensors.h
static inline int sensors_open_1(const struct hw_module_t* module,
        sensors_poll_device_1_t** device) {
    return module->methods->open(module,
            SENSORS_HARDWARE_POLL, (struct hw_device_t**)device);
}

static inline int sensors_close_1(sensors_poll_device_1_t* device) {
    return device->common.close(&device->common);
}

回過頭去看看HMI的結構體定義，其中module->common->open被賦值為sensors_module_methods，其只有一個open方法，因此，module->methods->open最終會呼叫sensors_open方法來開啟驅動程式。

到這裡native到hal層的邏輯其實已經基本上分析完了。

總結

通過hw_get_module去載入我們的HAL層實現庫，並且得到入口函式控制代碼，拿著這個控制代碼就可以繼而操作HAL層提供的方法了，通過上面的分析，相信大家已經對這部分已經有了一個更清晰的認識，其他hal層的業務邏輯大抵如此，當你看到hw_get_module，你就該知道去哪裡看接下來的邏輯了。

後續sensors_open的內容，我會在後面的章節連載剖析，歡迎關注。