自 2025 年 3 月 27 日起,我們建議您使用 android-latest-release
而非 aosp-main
建構及貢獻 AOSP。詳情請參閱「Android 開放原始碼計畫變更」。
舊版 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
的指標,而 hw_module_methods_t
則包含指向模組開放函式的指標。這個開放函式可用於與 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 和/或其關係企業的商標或註冊商標。
上次更新時間: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"]],["上次更新時間: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."]]