2025 年 3 月 27 日より、AOSP のビルドとコントリビューションには aosp-main
ではなく android-latest-release
を使用することをおすすめします。詳細については、AOSP の変更をご覧ください。
従来型 HAL
コレクションでコンテンツを整理
必要に応じて、コンテンツの保存と分類を行います。
HAL は、ハードウェア ベンダーが実装する標準インターフェースを定義することで、下位レベルのドライバ実装に Android が依存しないようにするものです。HAL を使用すると、上位レベルのシステムに影響や変更を加えることなく、機能を実装できます。このページでは、以前のアーキテクチャについて説明します。このアーキテクチャは Android 8.0 ではサポートされなくなりました。Android 8.0 以上については、HAL の概要をご覧ください。
図 1. HAL コンポーネント
プロダクトが特定のハードウェアを提供する場合、それに対応する HAL(およびドライバ)を実装する必要があります。HAL 実装は通常、共有ライブラリ モジュール(.so
ファイル)に組み込まれますが、HAL 実装とデバイス ドライバ間の標準的な通信は必須ではありません。状況に合わせて実装できます。ただし、Android システムがハードウェアと正しく通信できるようにするには、各ハードウェア固有の HAL インターフェースで定義されているコントラクトを遵守する必要があります。
HAL が予測可能な構造となるように、各ハードウェア固有の HAL インターフェースには hardware/libhardware/include/hardware/hardware.h
に定義されたプロパティがあります。このインターフェースにより、Android システムは正しいバージョンの HAL モジュールを一貫した方法で読み込むことができます。HAL インターフェースには、モジュールとデバイスの 2 つのコンポーネントがあります。
HAL モジュール
1 つのモジューがパッケージ化された HAL 実装を表し、共有ライブラリ(.so file
)として保存されます。hardware/libhardware/include/hardware/hardware.h
ヘッダー ファイルで、モジュールを表す構造体(hw_module_t
)を定義し、モジュールのバージョン、名前、作成者などのメタデータを指定します。Android は、このメタデータを使用して、HAL モジュールを正しく検出して読み込みます。
さらに、hw_module_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 オーディオ デバイス、または Bluetooth 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、無線インターフェース レイヤ、Bluetooth など)では、その他の標準化されていないインターフェースが libhardware_legacy に含まれていたり、コードベース全体に散在していたりします。レガシー HAL は強固な安定性を保証するものではありませんでした。
このページのコンテンツやコードサンプルは、コンテンツ ライセンスに記載のライセンスに従います。Java および OpenJDK は Oracle および関連会社の商標または登録商標です。
最終更新日 2025-07-27 UTC。
[[["わかりやすい","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 UTC。"],[],[],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."]]