Android HAL概述

小涂Ss

已于 2023-03-24 16:53:20 修改

阅读量1.7k

点赞数 2

文章标签： android java 开发语言

于 2023-03-24 14:29:32 首次发布

本文链接：https://blog.csdn.net/Gaga246/article/details/129750132

版权

Android HAL

Android HAL(Hardware Abstract Layer)硬件抽象层，从字面意思可以看出是对硬件设备的抽象和封装，为Android在不同硬件设备提供统一的访问接口。HAL处于Android framework和Linux kernel driver之间，HAL存在的意义有以下2个方面：

HAL屏蔽了不同硬件设备的差异，为Android提供了统一的访问硬件设备的接口。不同的硬件厂商遵循HAL标准来实现自己的硬件控制逻辑，但开发者不必关心不同硬件设备的差异，只需要按照HAL提供的标准接口访问硬件就可以了。
HAL层帮助硬件厂商隐藏了设备相关模块的核心细节。硬件厂商处于利益考虑，不希望公开硬件设备相关的实现细节；有了HAL层之后，他们可以把一些核心的算法之类的东西的实现放在HAL层，而HAL层位于用户空间，不属于linux内核，和android源码一样遵循的是Apache license协议，这个是可以开源或者不开的。

先看下 Android Camera HAL Module 是如何定义的:

static hw_module_methods_t v4l2_module_methods = {
    .open = v4l2_camera_hal::open_dev};

camera_module_t HAL_MODULE_INFO_SYM __attribute__((visibility("default"))) = {
    .common =
        {
            .tag = HARDWARE_MODULE_TAG,
            .module_api_version = CAMERA_MODULE_API_VERSION_2_4,
            .hal_api_version = HARDWARE_HAL_API_VERSION,
            .id = CAMERA_HARDWARE_MODULE_ID,
            .name = "V4L2 Camera HAL v3",
            .author = "The Android Open Source Project",
            .methods = &v4l2_module_methods,
            .dso = nullptr,
            .reserved = {0},
        },
    .get_number_of_cameras = v4l2_camera_hal::get_number_of_cameras,
    .get_camera_info = v4l2_camera_hal::get_camera_info,
    .set_callbacks = v4l2_camera_hal::set_callbacks,
    .get_vendor_tag_ops = v4l2_camera_hal::get_vendor_tag_ops,
    .open_legacy = v4l2_camera_hal::open_legacy,
    .set_torch_mode = v4l2_camera_hal::set_torch_mode,
    .init = nullptr,
    .reserved = {nullptr, nullptr, nullptr, nullptr, nullptr}};

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;

HMI

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

每个 module 必须提供一个名字为 HMI 的结构体
HMI 结构体的第一个字段必须是 hw_module_t

tag

#define MAKE_TAG_CONSTANT(A,B,C,D) (((A) << 24) | ((B) << 16) | ((C) << 8) | (D))

#define HARDWARE_MODULE_TAG MAKE_TAG_CONSTANT('H', 'W', 'M', 'T')
#define HARDWARE_DEVICE_TAG MAKE_TAG_CONSTANT('H', 'W', 'D', 'T')

tag 必须是: HARDWARE_MODULE_TAG

module_api_version

API version. 当 moduel interface 改变后 module owner 需要更新 API version.
module user 必须解释 API version 以决定是否与该 module 实现进行互操作。
例如: SurfaceFlinger 必须负责确保它知道如何管理不同版本的 gralloc-module API.
API version 包含一个 major 和一个 minor component.
例如: version 1.0 可以由 0x0100 表示.这种格式表示的范围: 0x0100-0x01ff
未来, libhardware 将会实现一个 hw_get_module_version() 函数, 该函数接受 minmux/maximum supported versions 作为参数,并且可以拒绝超出范围的 version.

hal_api_version

The API version of the HAL module interface.
指示 hw_module_t, hw_module_methods_t, hw_device_t.
HAL interface 拥有次字段. Module users/implementations 必须不依赖于它.
目前, 0 是非法的.

hw_module_methods_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;

hw_module_methods_t 指定了 module 的入口函数.

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;

version

Version of the module-specific device API. derived-module user 使用该字段管理不同的 device implementatsion.
不同版本的 module 可以支持多个设备.在设备接口以不兼容的方式改变时,version字段就会非常有用,但是同时支持较老的实现是必要的.例如 Camera2.0 API.
version 字段由 module user 解释,并且被 HAL interface 忽略.

看下 camera_device_t:

typedef struct camera_device {
    /**
     * camera_device.common.version must be in the range
     * HARDWARE_DEVICE_API_VERSION(0,0)-(1,FF). CAMERA_DEVICE_API_VERSION_1_0 is
     * recommended.
     */
    hw_device_t common;
    camera_device_ops_t *ops;
    void *priv;
} camera_device_t;

更多关于Android HAL 开发的学习资料考研扫码免费领取！

《Android八大模块进阶资料》

这里给大家分享一套由阿里高级架构师编写的《Android八大模块进阶资料》，帮助大家将杂乱、零散、碎片化的知识进行体系化的整理，让大家系统而高效地掌握Android开发的各个知识点。

内容简介：《架构师筑基必备技能》、《Android百大框架源码解析》、《Android性能优化实战解析》、《高级kotlin强化实战》、《Android高级UI开源框架进阶解密》、《NDK模块开发》、《Flutter技术进阶》、《微信小程序开发》。附全套视频资料，包含面试合集、源码合集、开源框架合集。

内容特点：资料一共8大模块、729个知识点，3382页，66万字，可以说覆盖了当下Android开发最前沿的技术点以及阿里、腾讯、字节跳动这些大厂面试时最看重的技术。

**由于文章内容比较多，篇幅有限，资料已经被整理成了PDF文档，有需要《****Android八大模块进阶资料》**完整文档的可以加微信即可免费领取!

### **目录**