HAL（Hardware Abstract Layer）硬件抽象層工作原理
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源碼一樣遵循的是Apache協議，這個是可以不用開源的。
以上就是HAL層存在的意義，下面來根據HAL層源碼分析一下HAL到底是怎麼樣個架構和實現原理，深入剖析一下。
HAL重要數據結構
android HAL層的代碼主要位於/hardware/libhardware下面我們從上往下走。
在HAL層中，各類硬件的都是以硬件模塊的形式描述的，是用hw_module_t結構體來描述的，而每一類硬件模塊中又有各個獨立的硬件，是用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;
/**
* 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;
/** 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;//打開硬件模塊的庫時得到的句柄
#ifdef __LP64__
uint64_t reserved[32-7];
#else
/** padding to 128 bytes, reserved for future use */
uint32_t reserved[32-7];
#endif
} hw_module_t;
B. 下面我們再來看看hw_device_t結構體,這個結構體主要是用來描述模塊中硬件設備的屬性信息什麼的。一個硬件模塊可能有多個硬件設備。比如說，傳感器模塊，sensor_module,是一個硬件模塊，但是手機中的傳感器就對應的有好多種，比如加速度acc_sensor,磁傳感器M_sensor等，那麼他們都屬於sensor_module,但是他們有都有自己的hw_device_t結構體來描述。hw_device_t定義如下：
/**
* Every device data structure must begin with hw_device_t
* followed by module specific public methods and attributes.
*/
typedef struct hw_device_t {
/** tag must be initialized to HARDWARE_DEVICE_TAG */
uint32_t 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 */
#ifdef __LP64__
uint64_t reserved[12];
#else
uint32_t reserved[12];
#endif
/** Close this device */
int (*close)(struct hw_device_t* device);//關閉設備的函數指針
} hw_device_t;
其中，第三個成員module指向的是這個設備歸屬的硬件模塊結構體。
最後一個函數指針close指向的肯定是關閉設備的函數。
到此，HAL的主要的兩個結構體講完了，下面我們繼續，將結合源碼，看看hal層到底是怎麼工作的，看看上層怎麼獲取到硬件模塊，硬件設備的，到底是怎麼加載解析動態共享庫的。
HAL實現原理
我們知道，一些硬件廠商不願意將自己的一些核心代碼開放出去，所以將這些代碼放到HAL層，但是怎麼保證它不開放呢？HAL層代碼不是也讓大家知道下載嗎？其實硬件廠商的HAL核心代碼是以共享庫的形式出現的，每次在需要的時候，HAL會自動加載調用相關共享庫。那麼是怎麼加載找到某一硬件設備對應的共享庫的呢？這也是我們都要說的。
上層APP通過JNI調用HAL層的hw_get_module函數獲取硬件模塊，這個函數是上層與HAL打交道的入口。所以如果我們以程序調用執行的流程去看源碼的話，這個函數就是HAL層第一個被調用的函數，下面我們就
沿着程序執行的流程走下去。比如說在frameworks\native\services\sensorservice\SensorDevice.cpp中
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);
}
}
}
}
這裏調用hw_get_module()得到硬件模塊結構體hw_module_t.有了hw_module_t,通過其內部的method open就能打開硬件模塊對應的設備了，通過結構體中的一些方法就能操作硬件設備了。
接下來我們看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);
}
這是其函數原型，傳入的參數id對應硬件設備的id，這是一個字符串，比如我們比較熟悉的sensor的id是SENSORS_HARDWARE_MODULE_ID，這個跟HAL_MODULE_INFO_SYM結構體中id的定義一樣，這個將在下面講到。hw_get_module函數根據這個id去查找匹配和這個id對應的硬件模塊結構體的。如果找到了對應的hw_module_t結構體，會將其指針放入*module中。
然後我們進入hw_get_module_by_class（）看看它具體實現：
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);//拷貝hardware id，name爲sensor
/*
* 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);//先嚐試獲取ro.hardware.sensor的屬性值
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) {//獲取數組variant_keys裏面的屬性值
continue;
}
if (hw_module_exists(path, sizeof(path), name, prop) == 0) {
goto found;
}
}
/* Nothing found, try the default */ //當所有變種名稱形式的包都不存在時，就以"id.default.so"形式包名查找是否存在
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);//裝載庫，得到module
}
prop這個變量的值是前面property_get(variant_keys[i], prop, NULL)函數獲取到的，其實這個函數是通過ariant_keys數組的屬性查找到系統中對應的變種名稱。不同的平臺獲取到prop值是不一樣的。然後將參數傳入hw_module_exists（）函數進行判斷該庫是否存在。
hw_module_exists如下：
/*
* Check if a HAL with given name and subname exists, if so return 0, otherwise
* otherwise return negative. On success path will contain the path to the HAL.
*/
static int hw_module_exists(char *path, size_t path_len, const char *name,
const char *subname)
{
snprintf(path, path_len, "%s/%s.%s.so",//查找動態鏈接庫的兩個路徑 vendor/lib/hw/ system/lib/hw
HAL_LIBRARY_PATH2, name, subname);
if (access(path, R_OK) == 0)
return 0;
snprintf(path, path_len, "%s/%s.%s.so",
HAL_LIBRARY_PATH1, name, subname);
if (access(path, R_OK) == 0)
return 0;
return -ENOENT;
}
該函數先拼湊出path，結合 HAL_LIBRARY_PATH2 爲"/vendor/lib/hw"，假設獲取到的prop值是tout，需要獲取的硬件模塊的id是leds，這種情況下path拼出來的值是/vender/lib/hw/leds.tout.so,然後在判斷文件是否存在。存在返回0.
variant_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"
};
上述代碼主要是搜索庫並獲取動態鏈接庫的路徑，然後調用load函數去加載指定路徑下的庫文件，load函數是關鍵所在。下面我們看看load（）：
/**
* Load the file defined by the variant and if successful
* return the dlopen handle and the hmi.
* @return 0 = success, !0 = failure.
*/
static int load(const char *id,
const char *path,
const struct hw_module_t **pHmi)//傳入硬件模塊id和庫所在路徑，獲取到硬件模塊結構體
{
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就是模塊結構的符號標誌
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) {//匹配解析出硬件模塊的id和傳入我們實際想要得到的模塊id是否一致。
ALOGE("load: id=%s != hmi->id=%s", id, hmi->id);
status = -EINVAL;
goto done;
}
hmi->dso = handle;//將打開庫得到的句柄傳給硬件模塊的dso
/* 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;//返回找到的模塊結構，賦值給module
return status;
}
可以看到load函數傳入的幾個參數，第一個參數就是需要加載的硬件模塊對應動態庫的硬件模塊的id，
第二個參數就是動態庫存放的路徑，就是在hw_get_module函數前部分搜索庫得到的path，
第三個參數就是我們需要得到的硬件模塊結構體，通過它傳給hw_get_module，hw_get_module函數在通過參數傳給jni。
首先調用dlopen打開共享庫，該函數通過傳入的庫的路徑找到庫，並且打開它，傳回一個操作句柄handle，然後再調用dlsym函數解析這個打開的庫，得到庫中包含的對應的硬件模塊結構體，並將它返回回來。所有硬件廠商或者硬件移植者都必須根據HAL的這個架構去實現填充這個和自己硬件相關的硬件模塊結構體hw_module_t，供使用。
通過dlsym解析之後就得到了hw_module_t，將從庫中解析得到的結構體中的id和傳入的id做比較，看是否一致。如果一致則證明就是得到正確的硬件模塊了。
最後將hw_module_t結構體指針傳給第三個參數，傳給hw_get_module函數。
提醒一下，HAL_MODULE_INFO_SYM_AS_STR這個宏很重要：
/** * Name of the hal_module_info as a string */ #define HAL_MODULE_INFO_SYM_AS_STR "HMI"
硬件抽象層中的每一個模塊都必須存在一個導出符號HAL_MODULE_IFNO_SYM，即「HMI」，它指向一個自定義的硬件抽象層模塊結構體。以sensor爲例，在\hardware\libhardware\modules\sensors\multihal.cpp下
struct sensors_module_t HAL_MODULE_INFO_SYM = {
common :{
tag : HARDWARE_MODULE_TAG,
version_major : 1,
version_minor : 1,
id : SENSORS_HARDWARE_MODULE_ID,
name : "MultiHal Sensor Module",
author : "Google, Inc",
methods : &sensors_module_methods,
dso : NULL,
reserved : {0},
},
get_sensors_list : module__get_sensors_list
};
這裏定義了一個名爲HAL_MODULE_INFO_SYM的sensors_module_t的結構體，事實上每個硬件模塊都必須定義一個變量名爲HAL_MODULE_INFO_SYM的結構體，而且common成員爲hw_module_t類型（這段話在定義hw_module_t結構體時有說明）。注意這裏的HAL_MODULE_INFO_SYM變量必須爲這個名字，這樣編譯器纔會將這個結構體的導出符號變爲「HMI」，dlsym函數才能找到這個結構體，才能根據符號返回符號對應的模塊地址。
模塊方法的實現
另外在hw_module_t結構體中定義了struct hw_module_methods_t* methods; hw_module_methods_t
這個指針methods它指向的是與本硬件模塊相關的方法的結構體，裏面不用看可以猜出肯定有一些函數指針，但是它裏面只有一個函數指針。可以看看定義：
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;
我們可以看到確實只有一個函數指針，open它是打開硬件模塊中硬件設備的函數。
以sensors爲例，在hardware\libhardware\modules\sensors\multihal.cpp中有關於sensors打開設備的方法定義代碼如下
static struct hw_module_methods_t sensors_module_methods = {
open : open_sensors
};
我們進入open_sensors，看看其具體實現：
static int open_sensors(const struct hw_module_t* hw_module, const char* name,
struct hw_device_t** hw_device_out) {
ALOGV("open_sensors begin...");
lazy_init_modules();
// Create proxy device, to return later.
sensors_poll_context_t *dev = new sensors_poll_context_t();
memset(dev, 0, sizeof(sensors_poll_device_1_t));
dev->proxy_device.common.tag = HARDWARE_DEVICE_TAG;
dev->proxy_device.common.version = SENSORS_DEVICE_API_VERSION_1_3;
dev->proxy_device.common.module = const_cast<hw_module_t*>(hw_module);
dev->proxy_device.common.close = device__close;
dev->proxy_device.activate = device__activate;
dev->proxy_device.setDelay = device__setDelay;
dev->proxy_device.poll = device__poll;
dev->proxy_device.batch = device__batch;
dev->proxy_device.flush = device__flush;
dev->nextReadIndex = 0;
// Open() the subhal modules. Remember their devices in a vector parallel to sub_hw_modules.
for (std::vector<hw_module_t*>::iterator it = sub_hw_modules->begin();
it != sub_hw_modules->end(); it++) {
sensors_module_t *sensors_module = (sensors_module_t*) *it;
struct hw_device_t* sub_hw_device;
int sub_open_result = sensors_module->common.methods->open(*it, name, &sub_hw_device);
if (!sub_open_result) {
if (!HAL_VERSION_IS_COMPLIANT(sub_hw_device->version)) {
ALOGE("SENSORS_DEVICE_API_VERSION_1_3 is required for all sensor HALs");
ALOGE("This HAL reports non-compliant API level : %s",
apiNumToStr(sub_hw_device->version));
ALOGE("Sensors belonging to this HAL will get ignored !");
}
dev->addSubHwDevice(sub_hw_device);
}
}
// Prepare the output param and return
*hw_device_out = &dev->proxy_device.common;
ALOGV("...open_sensors end");
return 0;
}
可以看到裏面對設備的一些賦值
以上是我這兩天學習硬件抽象層知識的一些總結。