Android HAL 层

简介: Android HAL 层

Android系统为硬件抽象层中的模块接口定义了编写规范,我们必须按照这个规范来编写自己的硬件模块接口。


Android系统的硬件抽象层模块的形式来管理各个硬件访问接口每一个硬件模块都对应有一个动态链接库文件,这些动态链接库文件的命名需要符合一定的规范。同时,在系统内部,每一个硬件抽象层模块都是用结构体**hw_module_t来描述,而硬件设备则使用结构体**hw_device_t来描述。


硬件抽象层模块文件的命名规范

hardware/libhardware/hardware.c

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

硬件抽象模块文件的命名规范为**“<MODULE_ID>.variant.so”**,其中MODULE_ID 标识模块的ID,variant 表示四个系统属性 ro.hardware、ro.product.board、ro.board.platform、ro.arch之一。

系统在加载硬件抽象层模块时,依次按照 ro.hardware.MODULE_ID、ro.hardware、

ro.product.board、ro.board.platform、ro.arch的顺序来取他们的属性值。如果其中一个系统属性存在,那么就把它的值作为variant的值,然后在检查对应的文件是否存在,如果存在,那么就找到要加载的硬件抽象层文件了;如果四个属性都不存在,或者四个属性对应的系统硬件抽象层文件不存在,就用 “<MODULE_ID>.default.so” 来作为要加载的硬件抽象层模块文件的名称。


硬件抽象层模块结构体定义规范

hardware\libhardware\include\hardware\hardware.h

struct hw_module_t;
struct hw_module_methods_t;
struct hw_device_t;
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;
 
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.
 */
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;


硬件抽象层中的硬件设备是由其所在的模块提供接口来打开的,而关闭是由硬件设备自身提供接口来完成的


硬件抽象层模块文件实际上是一个动态链接库文件,即so库文件。因此,首先调用dlopen函数将他加载到内存中


接着通过dlsym函数来获得里面名称为HAL_MODULE_INFO_SYM_AS_STR的符号。这个HAL_MODULE_INFO_SYM_AS_STR指向的是一个自定义硬件抽象层模块结构体,它包含了对应的硬件抽象层模块的所有信息。HAL_MODULE_INFO_SYM_AS_STR是一个宏,它的值定义为“HMI”


根据硬件抽象层的编写规范,每一个硬件抽象层模块都必须包含一个名称为HMI的符号,而且这个符号的第一个成员变量的类型必须是hw_module_t,因此,可以安全的将模块中的HMI符号转换成一个hw_module_t结构体指针。


得到hw_module_t指针之后,通过 strcmp函数来验证加载得到的硬件抽象层ID是否与所要求加载的硬件抽象层模块ID一致。如果不一致,就说明出错了,函数返回一个错误值: -EINVAL、


最后将成功加载后得到的模块句柄值handle保存在hw_module_t结构体指针hmi的成员变量dso中,然后将它返回给调用者。

 


目录
相关文章
|
6月前
|
安全 编译器 API
Android HAL深入探索(5): 调试HAL报错与解决方案
Android HAL深入探索(5): 调试HAL报错与解决方案
1135 1
|
6月前
|
传感器 Java Android开发
Android HAL深入探索(1): 架构概述
Android HAL深入探索(1): 架构概述
606 1
|
6月前
|
编解码 调度 Android开发
Android音频框架之一 详解audioPolicy流程及HAL驱动加载与配置
Android音频框架之一 详解audioPolicy流程及HAL驱动加载与配置
627 0
|
6月前
|
Android开发 C++
Android S HAL库的编译
Android S HAL库的编译
72 0
|
6月前
|
Android开发 C++
Android P HAL层添加HIDL实例
Android P HAL层添加HIDL实例
114 0
|
6月前
|
前端开发 Java 编译器
Android HAL深入探索(7)hidl-gen和hidl2aidl的使用详解
Android HAL深入探索(7)hidl-gen和hidl2aidl的使用详解
910 0
|
6月前
|
编解码 监控 API
Android HAL深入探索(6): HIDL 添加SELinux 完整调试过程
Android HAL深入探索(6): HIDL 添加SELinux 完整调试过程
938 0
|
Java Android开发
Android10.0(Q) HAL层 light2.0 改动记录及排错过程
Android10.0(Q) HAL层 light2.0 改动记录及排错过程
1071 0