自 2025 年 3 月 27 日起,我们建议您使用 android-latest-release
而非 aosp-main
构建 AOSP 并为其做出贡献。如需了解详情,请参阅 AOSP 的变更。
旧版 HAL
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
HAL 可定义一个标准接口以供硬件供应商实现,这可让 Android 忽略较低级别的驱动程序实现。借助 HAL,您可以顺利实现相关功能,而不会影响或更改更高级别的系统。本页面介绍了自 Android 8.0 开始已不再支持的旧版架构。对于 Android 8.0 及更高版本,请参阅 HAL 概览。
图 1. HAL 组件
您必须为您的产品所提供的特定硬件实现相应的 HAL(和驱动程序)。HAL 实现通常会内置在共享库模块(.so
文件)中,但 Android 并未规定 HAL 实现与设备驱动程序之间交互的标准方式,因此您可以视情况采取适当的做法。不过,为了让 Android 系统能够与硬件正确交互,您必须遵守每个硬件专用 HAL 接口中的相关规定。
为了保证 HAL 具有可预测的结构,每个硬件专用 HAL 接口都要具有在 hardware/libhardware/include/hardware/hardware.h
中定义的属性。这类接口可让 Android 系统以一致的方式加载 HAL 模块的正确版本。HAL 接口包含两个组件:模块和设备。
HAL 模块
模块代表打包的 HAL 实现,这种实现存储为共享库 (.so file
)。hardware/libhardware/include/hardware/hardware.h
头文件可定义一个代表模块的结构体 (hw_module_t
),其中包含模块的版本、名称和作者等元数据。Android 会根据这些元数据来找到并正确加载 HAL 模块。
另外,hw_module_t
结构体还包含指向另一个结构体 hw_module_methods_t
的指针,后面这个结构体包含指向相应模块的 open 函数的指针。此 open 函数用于与相关硬件(此 HAL 是其抽象形式)建立通信。每个硬件专用 HAL 通常都会使用该特定硬件的附加信息来扩展通用的 hw_module_t
结构体。例如,在相机 HAL 中,camera_module_t
结构体包含一个 hw_module_t
结构体以及相机专用的其他函数指针:
typedef struct camera_module {
hw_module_t common;
int (*get_number_of_cameras)(void);
int (*get_camera_info)(int camera_id, struct camera_info *info);
} camera_module_t;
实现 HAL 并创建模块结构体时,您必须将其命名为 HAL_MODULE_INFO_SYM
。以下是 Nexus 9 音频 HAL 的示例:
struct audio_module HAL_MODULE_INFO_SYM = {
.common = {
.tag = HARDWARE_MODULE_TAG,
.module_api_version = AUDIO_MODULE_API_VERSION_0_1,
.hal_api_version = HARDWARE_HAL_API_VERSION,
.id = AUDIO_HARDWARE_MODULE_ID,
.name = "NVIDIA Tegra Audio HAL",
.author = "The Android Open Source Project",
.methods = &hal_module_methods,
},
};
HAL 设备
设备是产品硬件的抽象表示。例如,一个音频模块可能包含主音频设备、USB 音频设备或蓝牙 A2DP 音频设备。
设备由 hw_device_t
结构体表示。与模块类似,每类设备都定义了一个通用 hw_device_t
的详细版本,其中包含指向特定硬件功能的函数指针。例如,audio_hw_device_t
结构体类型会包含指向音频设备操作的函数指针:
struct audio_hw_device {
struct hw_device_t common;
/**
* used by audio flinger to enumerate what devices are supported by
* each audio_hw_device implementation.
*
* Return value is a bitmask of 1 or more values of audio_devices_t
*/
uint32_t (*get_supported_devices)(const struct audio_hw_device *dev);
...
};
typedef struct audio_hw_device audio_hw_device_t;
除了这些标准属性之外,每个特定于硬件的 HAL 接口都可以定义更多的自有功能和要求。有关详情,请参阅 HAL 参考文档以及各 HAL 的单独说明。
构建 HAL 模块
HAL 实现会内置在模块 (.so
) 文件中,并由 Android 适时地动态关联。您可通过为每个 HAL 实现创建 Android.mk
文件并指向源文件来构建模块。一般来说,您的共享库必须以特定格式命名,以方便找到并正确加载。各模块的命名方案略有不同,但它们都遵循以下通用模式:<module_type>.<device_name>
。
旧版 HAL
旧版 HAL 泛指所有 Android 8.0 之前的 HAL(在 Android 8 中已废弃)。大多数 Android 系统接口(相机、音频、传感器等)都是在“hardware/libhardware/include/hardware”下定义的,具有粗略的版本控制和大致稳定的 ABI。一些子系统(包括 Wi-Fi、无线接口层和蓝牙)在“libhardware_legacy”中具有其他非标准化接口,或者这些非标准化接口散布在整个代码库中。旧版 HAL 从未提供硬性稳定性保证。
本页面上的内容和代码示例受内容许可部分所述许可的限制。Java 和 OpenJDK 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC):2025-07-27。
[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["没有我需要的信息","missingTheInformationINeed","thumb-down"],["太复杂/步骤太多","tooComplicatedTooManySteps","thumb-down"],["内容需要更新","outOfDate","thumb-down"],["翻译问题","translationIssue","thumb-down"],["示例/代码问题","samplesCodeIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC):2025-07-27。"],[],[],null,["# Legacy HALs\n\nA HAL defines a standard interface for hardware vendors to implement,\nwhich enables Android to be agnostic about lower-level driver implementations.\nUsing a HAL allows you to implement functionality without affecting or modifying\nthe higher level system. This page describes the older architecture, which is no\nlonger supported as of Android 8.0. For Android 8.0 and higher, please see the\n[HAL Overview](/docs/core/architecture/hal).\n\n**Figure 1.** HAL components\n\nYou must implement the corresponding HAL (and driver) for the specific\nhardware your product provides. HAL implementations are typically built into\nshared library modules (`.so` files), but as Android does not mandate\na standard interaction between a HAL implementation and device drivers, you can\ndo what is best for your situation. However, to enable the Android system to\ncorrectly interact with your hardware, you **must** abide by the\ncontract defined in each hardware-specific HAL interface.\n\nTo guarantee that HALs have a predictable structure, each hardware-specific\nHAL interface has properties defined in\n`hardware/libhardware/include/hardware/hardware.h`. This interface\nallows the Android system to load correct versions of your HAL modules in a\nconsistent way. A HAL interface consists of two components: modules and devices.\n\nHAL modules\n-----------\n\nA module represents your packaged HAL implementation, which is stored as a\nshared library (`.so file`). The\n`hardware/libhardware/include/hardware/hardware.h` header file\ndefines a struct (`hw_module_t`) that represents a module and\ncontains metadata such as the version, name, and author of the module. Android\nuses this metadata to find and load the HAL module correctly.\n\nIn addition, the `hw_module_t` struct contains a pointer to\nanother struct, `hw_module_methods_t`, that contains a pointer to\nan open function for the module. This open function is used to initiate\ncommunication with the hardware for which the HAL is serving as an abstraction.\nEach hardware-specific HAL usually extends the generic `hw_module_t`\nstruct with additional information for that specific piece of hardware. For\nexample, in the camera HAL, the `camera_module_t` struct contains a\n`hw_module_t` struct along with other camera-specific function\npointers: \n\n```\ntypedef struct camera_module {\n hw_module_t common;\n int (*get_number_of_cameras)(void);\n int (*get_camera_info)(int camera_id, struct camera_info *info);\n} camera_module_t;\n```\n\nWhen you implement a HAL and create the module struct, you must name it\n`HAL_MODULE_INFO_SYM`. Example from the Nexus 9 audio HAL: \n\n```\nstruct audio_module HAL_MODULE_INFO_SYM = {\n .common = {\n .tag = HARDWARE_MODULE_TAG,\n .module_api_version = AUDIO_MODULE_API_VERSION_0_1,\n .hal_api_version = HARDWARE_HAL_API_VERSION,\n .id = AUDIO_HARDWARE_MODULE_ID,\n .name = \"NVIDIA Tegra Audio HAL\",\n .author = \"The Android Open Source Project\",\n .methods = &hal_module_methods,\n },\n};\n```\n\nHAL devices\n-----------\n\nA device abstracts the hardware of your product. For example, an audio\nmodule can contain a primary audio device, a USB audio device, or a Bluetooth\nA2DP audio device.\n\nA device is represented by the `hw_device_t` struct. Similar to a\nmodule, each type of device defines a detailed version of the generic\n`hw_device_t` that contains function pointers for specific features\nof the hardware. For example, the `audio_hw_device_t` struct type\ncontains function pointers to audio device operations: \n\n```\nstruct audio_hw_device {\n struct hw_device_t common;\n\n /**\n * used by audio flinger to enumerate what devices are supported by\n * each audio_hw_device implementation.\n *\n * Return value is a bitmask of 1 or more values of audio_devices_t\n */\n uint32_t (*get_supported_devices)(const struct audio_hw_device *dev);\n ...\n};\ntypedef struct audio_hw_device audio_hw_device_t;\n```\n\nIn addition to these standard properties, each hardware-specific HAL\ninterface can define more of its own features and requirements. For details,\nsee the [HAL reference documentation](/reference/hal) as well as\nthe individual instructions for each HAL.\n\nBuild HAL modules\n-----------------\n\nHAL implementations are built into modules (`.so`) files and are\ndynamically linked by Android when appropriate. You can build your modules by\ncreating `Android.mk` files for each of your HAL implementations\nand pointing to your source files. In general, your shared libraries must be\nnamed in a specific format so they can be found and loaded properly. The naming\nscheme varies slightly from module to module, but follows the general pattern\nof: `\u003cmodule_type\u003e.\u003cdevice_name\u003e`.\n\nLegacy HAL\n----------\n\nThe term Legacy HAL refers broadly to all pre-Android 8.0 HALs (deprecated in Android 8). The bulk of Android system interfaces (camera, audio, sensors, etc.) are defined under \\`hardware/libhardware/include/hardware\\` and have rough versioning and a roughly stable ABI. A few subsystems (including Wi-Fi, Radio Interface Layer, and Bluetooth) have other non-standardized interfaces in \\`libhardware_legacy\\` or interspersed throughout the codebase. Legacy HALs never provided hard stability guarantees."]]