2025 年 3 月 27 日より、AOSP のビルドとコントリビューションには aosp-main
ではなく android-latest-release
を使用することをおすすめします。詳細については、AOSP の変更をご覧ください。
動的に使用可能な HAL
コレクションでコンテンツを整理
必要に応じて、コンテンツの保存と分類を行います。
Android 9 では、Android ハードウェアのサブシステムが使用されていない場合または不要な場合の動的なシャットダウンをサポートしています。たとえば、ユーザーが Wi-Fi を使用していない場合、Wi-Fi サブシステムがメモリ、電源、その他のシステム リソースを占有するのは望ましくありません。以前のバージョンの Android では、Android スマートフォンが起動している間ずっと、HAL / ドライバが Android デバイスで開いたままになっていました。
動的シャットダウンを実装する作業には、以下のセクションで説明するように、データフローの結合と動的プロセスの実行が含まれます。
HAL 定義の変更
動的シャットダウンでは、どのプロセスがどのような HAL インターフェースにサービスを提供するかについての情報が必要です(この情報は後で他のコンテキストでも役立ちます)。また、起動時にプロセスを起動せず、終了時に(再度リクエストされるまでは)プロセスを再起動しないことも必要です。
# some init.rc script associated with the HAL
service vendor.some-service-name /vendor/bin/hw/some-binary-service
# init language extension, provides information of what service is served
# if multiple interfaces are served, they can be specified one on each line
interface android.hardware.light@2.0::ILight default
# restarted if hwservicemanager dies
# would also cause the hal to start early during boot if disabled wasn't set
class hal
# will not be restarted if it exits until it is requested to be restarted
oneshot
# will only be started when requested
disabled
# ... other properties
init と hwservicemanager の変更
動的シャットダウンには、リクエストされたサービスの開始を init
に指示するための hwservicemanager
も必要です。Android 9 では、init
に含まれる制御メッセージ(ctl.start
など)に、ctl.interface_start
、ctl.interface_stop
、ctl.interface_restart
の 3 つのメッセージが追加されています。これらのメッセージを使用して、特定のハードウェア インターフェースの起動と停止を init
に指示することもできます。サービスがリクエストされ、そのサービスが登録されていない場合は、hwservicemanager
がサービスの開始をリクエストします。ただし、動的 HAL ではこれらのいずれも使用する必要はありません。
HAL の終了の決定
Android 9 では、HAL の終了を手動で決定する必要があります。Android 10 以上では、自動ライフサイクルで決定することもできます。
動的シャットダウンには、HAL をいつ起動していつシャットダウンするかを決めるためのポリシーが複数必要です。HAL がなんらかの理由で終了を決断した場合、HAL 定義で提供される情報と、init
と hwservicemanager
の変更により提供されるインフラストラクチャを使用して、必要に応じて HAL が自動的に再起動されます。これには、次のようなさまざまな戦略があります。
- HAL は、close または類似の API が HAL 上で呼び出された場合、HAL 上で exit を呼び出すことを選択できます。この動作は、対応する HAL インターフェースで指定する必要があります。
- タスクが完了すると、HAL はシャットダウンを実行できます(HAL ファイルに記述されています)。
自動ライフサイクル
Android 10 では、カーネルと hwservicemanager
に対するサポートが追加され、クライアントがない場合にいつでも HAL を自動的にシャットダウンできるようになりました。この機能を使用するには、HAL 定義の変更のすべてのステップに加えて、以下を行います。
- メンバー関数
registerAsService
の代わりに LazyServiceRegistrar
を使用して、C++ でサービスを登録します。例:
// only one instance of LazyServiceRegistrar per process
LazyServiceRegistrar registrar;
registrar.registerAsService(myHidlService /* , "default" */);
- HAL クライアントが、使用されているときにのみトップレベルの HAL(
hwservicemanager
に登録されているインターフェース)への参照を保持することを確認します。遅延を回避するために、実行を継続する hwbinder スレッドでこの参照が破棄された場合、参照の破棄後にクライアントが IPCThreadState::self()->flushCommands()
も呼び出すようにしてください。これにより、関連する参照カウントの変更がバインダ ドライバに通知されるようになります。
このページのコンテンツやコードサンプルは、コンテンツ ライセンスに記載のライセンスに従います。Java および OpenJDK は Oracle および関連会社の商標または登録商標です。
最終更新日 2025-07-26 UTC。
[null,null,["最終更新日 2025-07-26 UTC。"],[],[],null,["# Dynamically available HALs\n\nAndroid 9 supports the dynamic shutdown of Android hardware subsystems when they are not in use or not needed. For example, when a user is not using Wi-Fi, the Wi-Fi subsystems should not be taking up memory, power, or other system resources. In earlier versions of Android, HALs/drivers were kept open on Android devices for the entire duration an Android phone was booted.\n\nImplementing dynamic shutdown involves wiring up data flows and executing\ndynamic processes as detailed in the following sections.\n\nChanges to HAL definitions\n--------------------------\n\nDynamic shutdown requires information on which processes serve what HAL\ninterfaces (this information may also be useful later in other contexts) as\nwell as not starting processes on boot and not restarting them (until\nrequested again) when they exit. \n\n```objective-c\n# some init.rc script associated with the HAL\nservice vendor.some-service-name /vendor/bin/hw/some-binary-service\n # init language extension, provides information of what service is served\n # if multiple interfaces are served, they can be specified one on each line\n interface android.hardware.light@2.0::ILight default\n # restarted if hwservicemanager dies\n # would also cause the hal to start early during boot if disabled wasn't set\n class hal\n # will not be restarted if it exits until it is requested to be restarted\n oneshot\n # will only be started when requested\n disabled\n # ... other properties\n```\n\nChanges to init and hwservicemanager\n------------------------------------\n\nDynamic shutdown also requires the `hwservicemanager` to tell\n`init` to start requested services. In Android 9,\n`init` includes three additional control messages (e.g.\n`ctl.start`): `ctl.interface_start`,\n`ctl.interface_stop`, and `ctl.interface_restart`.\nThese messages can be used to signal `init` to bring up and down\nspecific hardware interfaces. When a service is requested and isn't\nregistered, `hwservicemanager` requests that the service be\nstarted. However, dynamic HALs don't require using any of these.\n\nDetermine HAL exit\n------------------\n\nIn Android 9, HAL exit has to be manually\ndetermined. For Android 10 and higher, it can also\nbe determined with\n[automatic lifecycles](#automatic-lifecycles).\n\nDynamic shutdown requires multiple policies for deciding when to start a\nHAL and when to shutdown a HAL. If a HAL decides to exit for any reason, it\nwill automatically be restarted when it is needed again using the information\nprovided in the HAL definition and the infrastructure provided by changes to\n`init` and `hwservicemanager`. This could involve a\ncouple of different strategies, including:\n\n- A HAL could choose to call exit on itself if someone calls a close or similar API on it. This behavior must be specified in the corresponding HAL interface.\n- HALs can shut down when their task is completed (documented in the HAL file).\n\nAutomatic lifecycles\n--------------------\n\nAndroid 10 adds more support to the kernel and\n`hwservicemanager`, which allows HALs to shut down automatically\nwhenever they have no clients. To use this feature, do all of the steps in\n[Changes to HAL definitions](#changes-HAL-definitions) as well\nas:\n\n- Register the service in C++ with `LazyServiceRegistrar` instead of the member function, `registerAsService`, for example: \n\n ```scilab\n // only one instance of LazyServiceRegistrar per process\n LazyServiceRegistrar registrar;\n registrar.registerAsService(myHidlService /* , \"default\" */);\n ```\n- Verify that the HAL client keeps a reference to the top-level HAL (the interface registered with `hwservicemanager`) only when it's in use. To avoid delays if this reference is dropped on a hwbinder thread that continues to execute, the client should also call `IPCThreadState::self()-\u003eflushCommands()` after dropping the reference to ensure that the binder driver is notified of the associated reference count changes."]]