最近要做的东西可能涉及HAL的概念，看看<<android源代码情景分析 >>
Headware Abstract Layer (HAL)
为什么Android的driver分UMD和KMD实现？
如果实现在UMD，遵循Apache license就可以闭源，做HAL层。
KMD遵循GPL，driver只提供简单硬件访问通道。android体系:
| Android体系 |
|---|
| App |
| App framework |
| lib&Runtime |
| HAL |
| ------------------上面是UMD，下面是KMD---------------------- |
| HAL |
| Driver |
| Process/Memory manager |
KMD Driver
HAL层
HAL层是一个硬件模块，是一个动态库so，其命名有命名规范。
内部:
| 结构体 | |
|---|---|
| 硬件抽象层 | hw_module_t |
| 硬件设备 | hw_device_t |
命名规范
结构体定义规范
//.h 声明结构体：
//自定义模块结构体，开头包含hw_module_t，
struct freg_module_t {
struct hw_module_t common; //里面有个hw_module_methods_t *method
};
//自定义设备结构体，开头包含hw_device_t
struct freg_device_t {
struct hw_device_t common;
int fd;
int (*own_func)();
};
//cpp 定义结构体：
//hw_module_mothods_t只有一个int (*open) (strcut hw_module_t* module, id, strcut hw_device_t** device)
struct hw_module_mothods_t freg_module_methods = {
.open : freg_device_open
};
struct freg_module_t HAL_MODULE_INFO_SYM = {
.common: { //填hw_module_t的结构体变量
tag： HARDWARE_MODULE_TAG, //必须为此
...
methods : &freg_module_methods, //传了open方法
}
}
int freg_device_open(struct hw_module_t *module, id, struct hw_device_t **device) {
struct frag_device_t *dev;
//填dev->common
//填dev->ownFunc = ownFunc();
}
//定义ownFunc();
//Andriod.mk
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE_TQAGS := optional
LOCAL_MODULE_PATH := $(TARGET_OUT_SHARED_LIBRARIES)/hw
LOCAL_SHARED_LIBRARIES := liblog
LOCAL_SRC_FILES := freg.cpp
LOCAL_MODULE := freg.default
include $(BUILD_SHARED_LIBRARY)
HAL的加载
//谁要使用HAL都要通过hw_get_module(struct hw_module_t **module)来拿到hw_module，
//这个module就是当年定义的HAL_MODULE_INFO_SYM
int hw_get_module(id, struct hw_module_t **module)
{
//asscess(path)查找可用路径
load(id, path, module);
}
int load(id, char *path, struct hw_module_t **pHmi)
{
void *handle = dlopen(path, RTLD_NOW);
//得到struct hal_module_info的地址
const char *sym = HAL_MODULE_INFO_SYM;
struct hw_module_t *hmi ;
hmi = (struct hw_module_t *)dlsym(handle, sym);
hmi->dso = handle;
*pHmi = hmi;
}
