2025 年 3 月 27 日より、AOSP のビルドとコントリビューションには aosp-main ではなく android-latest-release を使用することをおすすめします。詳細については、AOSP の変更をご覧ください。
USB HAL を実装する
コレクションでコンテンツを整理
必要に応じて、コンテンツの保存と分類を行います。
Android 8.0 リリースでは、USB コマンドの処理を init スクリプトからネイティブ USB デーモンに移行し、構成とコードの信頼性が向上しました。ガジェット機能の構成を設定する場合は、init スクリプト（プロパティ トリガー）を使用して、デバイス固有のガジェット操作を実行します。
以前のリリースでは、こうしたデバイス固有の構成を設定するために、プロパティ トリガーを用いたデバイス固有の init スクリプトを使用していました。ハードウェア抽象化レイヤ（HAL）での設計に移行したことで次のような問題が解決され、よりクリーンな実装ができるようになりました。
- カーネル sysfs ノードへの書き込みなどの操作でエラーが発生しても、プロパティ トリガーが設定されたフレームワーク コードまで伝わらず、エラーが返されないため、失敗したことに関して通知されない場合であってもフレームワークは操作が成功したと誤認識してしまう。
init スクリプトで実行可能な操作の回数に制限がある。
Android 12 リリースでは、ネットワーク制御モデル（NCM）と、HAL バージョン番号と USB 速度の両方を返す API 呼び出しに対する USB ガジェット HAL サポートが追加されています。USB HAL を通じて使用できる API 呼び出しについて詳しくは、android.hardware.usb パッケージの概要をご覧ください。
HAL と Treble
デバイス固有の init スクリプトは、デバイス固有の USB 操作を実行する HAL レイヤの代替として使用されました。USB（ADB 経由）は、システムで発生した問題をデバッグするための主要なインターフェースです。ネイティブ デーモンを USB 構成で実行するように設定するとフレームワーク コードとの依存関係がなくなるため、フレームワークがクラッシュした場合でも USB の実行は継続されます。
Android 8.0 で導入された Treble モデルでも、すべての HAL はシステム サービスから分離されているため、独自のネイティブ デーモンで実行する必要があります。これにより、HAL レイヤが USB デーモンとして適切に機能するようになるため、専用の USB デーモンを使用する必要がなくなります。
デフォルトの HAL 実装は、Android 8.0 より前のすべてのデバイスを対象としています。したがって、Android 8.0 より前のデバイスにはデバイス固有の処理というものがありません。Android 8.0 では、HAL インターフェースを使用して USB ポートのステータスのクエリを実行し、データロールとパワーロールの切り替えを行います。
実装
新しい USB HAL インターフェースは、Android 8.0 で起動するすべてのデバイスに実装する必要があります。
デフォルトの実装は、Android 8.0 より前のデバイスを対象としています。デバイスが Type-C のポート ステータスをレポートするために dual_role_usb クラスを使用する場合は、デフォルトの実装で十分です。Type-C のノードの所有権をシステムに移行するには、デバイス固有の USB スクリプトに若干の変更が必要になる場合があります。
このページのコンテンツやコードサンプルは、コンテンツ ライセンスに記載のライセンスに従います。Java および OpenJDK は Oracle および関連会社の商標または登録商標です。
最終更新日 2025-03-26 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-03-26 UTC。"],[],[],null,["# Implement USB HAL\n\nThe Android 8.0 release moves handling of USB commands out of `init`\nscripts and into a native USB daemon for better configuration and code\nreliability. For the Gadget function configuration, `init` scripts\n(property triggers) are used to perform device-specific gadget operations.\n\nIn previous releases, these device-specific configurations were achieved through\ndevice-specific `init` scripts (using property triggers). Moving to a\nHardware Abstraction Layer (HAL) design results in a much cleaner implementation\nthat solves these problems:\n\n1. Operations such as writes to the kernel sysfs nodes could fail but not be propagated back to the frameworks code that sets the property trigger. As a result, frameworks incorrectly assumes the operations have succeeded even though they have silently failed.\n2. `init` scripts have a limited number of operations that could be executed.\n\nThe Android 12 release adds USB Gadget HAL support for Network Control\nModels (NCM) and API calls that return both the HAL version number and USB speed. For more\ninformation on the API calls available through the USB HAL, see\n[the `android.hardware.usb` package summary](https://developer.android.com/reference/android/hardware/usb/package-summary).\n\nHAL and Treble\n--------------\n\n\nThe device-specific `init` scripts were used as a substitution for\nHAL layers to perform device-specific USB operations. USB (through ADB) is a\nprimary interface for debugging system issues. Having a native daemon to perform\nUSB configuration eliminates the dependency on the framework code so even if the\nframework crashes USB should be running.\n\n\nUnder the\n[Treble](https://android-developers.googleblog.com/2017/05/here-comes-treble-modular-base-for.html)\nmodel also introduced in Android 8.0, all of the HALs are isolated from System\nservices and are required to run in their own native daemons. This eliminates\nthe requirement to have an exclusive USB daemon as the HAL layer nicely doubles\nas a USB daemon.\n\n\nThe default HAL implementation takes care of all pre-Android 8.0 devices. Therefore, there\nwouldn't be any device-specific work for the pre-Android 8.0 devices. Android 8.0 uses the HAL\ninterface to query the status of USB ports and to perform data role and power\nrole swaps.\n\nImplementation\n--------------\n\n\nNew USB HAL interface needs to be implemented on every device launching on Android 8.0.\nThe default implementation should take care of pre-Android 8.0 devices. The default\nimplementation is sufficient if the device uses the `dual_role_usb` class to report\ntype-c port status. Trivial changes might be required in device-specific USB scripts\nto transfer ownership of the typc-c nodes to system."]]
