このページは Cloud Translation API によって翻訳されました。

センサーマルチHAL

Sensors Multi-HALは、センサーHALを他のセンサーHALと一緒に実行できるようにするフレームワークです。 Sensors Multi-HALは、ベンダーパーティションにダイナミックライブラリとして格納されているセンサーサブHALを動的にロードし、イベントの投稿とウェイクロックの取得と解放を処理できるコールバックオブジェクトを提供します。センサーサブHALは、ベンダーパーティションの共有オブジェクトに組み込まれ、マルチHALフレームワークによって使用されるセンサーHALです。これらのサブHALは、相互に依存したり、プロセスのメイン関数を含むマルチHALコードに依存したりすることはありません。

Android11以降を実行しているデバイスで利用可能なSensorsMulti-HAL 2.1は、Sensors Multi-HAL 2.0のイテレーションであり、ヒンジ角度センサータイプを公開できるサブHALの読み込みをサポートします。このセンサータイプをサポートするには、サブHALは2.1SubHalヘッダーで定義されたサブHALAPIを使用する必要があります。

センサーMulti-HAL2とセンサーHAL2の違い

Android10以降を実行しているデバイスで利用可能なSensorsMulti-HAL 2は、 Sensors HAL 2にいくつかの抽象化を導入して、HALAPIとの対話を容易にします。 Sensors Multi-HAL 2では、Sensors HAL2インターフェイスとV2_1/SubHal （またはV2_0/SubHal ）インターフェイスの実装を処理するHalProxyクラスが導入され、 HalProxyがサブHALと対話できるようになります。

ISensorsSubHalインターフェイスは、次の点で2.1/ISensors.hal （または2.0/ISensors.hal ）インターフェイスとは異なります。

initializeメソッドは、2つのFMQとISensorsCallbackの代わりにIHalProxyCallbackクラスを渡します。
サブHALは、バグレポートでデバッグ情報を提供するためのデバッグ機能を実装する必要があります。
サブHALは、ロードされたサブHALを他のサブHALと区別できるように、名前関数を実装する必要があります。

Sensors Multi-HAL2とSensorsHAL 2の主な違いは、初期化機能にあります。 IHalProxyCallbackインターフェイスは、FMQを提供する代わりに、2つのメソッドを提供します。1つはセンサーイベントをセンサーフレームワークに送信するメソッドで、もう1つはウェイクロックを作成するメソッドです。内部的には、Sensors Multi-HALはFMQとのすべての相互作用を管理して、すべてのサブHALのセンサーイベントをタイムリーに配信できるようにします。サブHALはcreateScopedWakelockメソッドを使用して、ウェイクロックのタイムアウトの負担をSensors Multi-HALに委任し、WakeLockの使用をSensorsMulti-HAL全体の1つの共通のウェイクロックに集中させることを強くお勧めします。これにより、ロックとロック解除が最小限に抑えられます。呼び出します。

Sensors Multi-HAL 2には、いくつかの安全機能も組み込まれています。センサーFMQがいっぱいになった場合や、Androidセンサーフレームワークが再起動してセンサーの状態をリセットする必要がある場合に対応します。さらに、イベントがHalProxyクラスに投稿されたが、センサーフレームワークがイベントをすぐに受け入れることができない場合、Sensors Multi-HALはイベントをバックグラウンドスレッドに移動して、イベントを待機している間、すべてのサブHALで作業を続行できるようにします。投稿されます。

ソースコードとリファレンス実装

すべてのセンサーMulti-HALコードは、 hardware/interfaces/sensors/common/default/2.X/multihal/で利用できます。ここにいくつかのリソースへのポインタがあります。

HalProxy.h ： HalProxyオブジェクトはSensors multi-HALによってインスタンス化され、サブHALからセンサーフレームワークへのデータの受け渡しを処理します。
HalProxy.cpp ： HalProxyの実装には、サブHALとセンサーフレームワーク間の通信を多重化するために必要なすべてのロジックが含まれています。
SubHal.h ： ISensorsSubHalインターフェイスは、 HalProxyと互換性を持たせるためにサブHALが従う必要のあるインターフェイスを定義します。サブHALは、 HalProxyCallbackオブジェクトをpostEventsおよびcreateScopedWakelockに使用できるように、initializeメソッドを実装します。
Multi-HAL 2.0の実装には、 SubHal.hのバージョン2.0を使用します。
hardware/interfaces/sensors/common/default/2.X/multihal/tests/ ：これらの単体テストはHalProxyの実装を検証します。
hardware/interfaces/sensors/common/default/2.X/multihal/tests/fake_subhal/ ：このサブHAL実装の例では、偽のセンサーを使用して偽のデータを生成します。複数のサブHALがデバイス上でどのように相互作用するかをテストするのに役立ちます。

実装

このセクションでは、次の状況でSensorsMulti-HALを実装する方法について説明します。

センサーの実装Multi-HAL2.1
センサーMulti-HAL2.0からMulti-HAL2.1への移植
センサーHAL2.0からの移植
センサーHAL1.0からの移植
センサーからの移植Multi-HAL1.0

センサーの実装Multi-HAL2.1

新しいデバイスにSensorsMulti-HAL 2.1を実装するには、次の手順に従います。

SubHal.hで説明されているように、 ISensorsSubHalインターフェイスを実装します。
SubHal.hにsensorsHalGetSubHal_2_1メソッドを実装します。
cc_library_sharedターゲットを追加して、新しく実装されたサブHALを構築します。ターゲットを追加する場合：
1. ターゲットがデバイスのベンダーパーティションのどこかにプッシュされていることを確認します。
2. /vendor/etc/sensors/hals.confにある構成ファイルで、ライブラリへのパスを新しい行に追加します。必要に応じて、 hals.confファイルを作成します。
サブHALライブラリを構築するためのAndroid.bpエントリの例については、 hardware/interfaces/sensors/common/default/2.X/multihal/tests/Android.bpを参照してください。
デバイスでサポートされているHALのリストが含まれているmanifest.xmlファイルからすべてのandroid.hardware.sensorsエントリを削除します。
device.mkファイルからすべてのandroid.hardware.sensorsサービスおよびservice.rcファイルを削除し、 android.hardware.sensors@2.1-service.multihal.rc android.hardware.sensors@2.1-service.multihal PRODUCT_PACKAGESに追加します。

起動時に、 HalProxyが起動し、新しく実装されたサブHALを探し、 sensorsHalGetSubHal_2_1を呼び出して初期化します。

センサーMulti-HAL2.0からMulti-HAL2.1への移植

Multi-HAL2.0からMulti-HAL2.1に移植するには、 SubHalインターフェイスを実装し、サブHALを再コンパイルします。

2.0と2.1のSubHalインターフェイスの違いは次のとおりです。

IHalProxyCallbackは、バージョン2.1のISensors.hal仕様で作成されたタイプを使用します。
initialize()関数は、2.0 SubHalインターフェイスからのものではなく、新しいIHalProxyCallbackを渡します。
サブHALは、 getSensorsList injectSensorData_2_1 getSensorsList_2_1 injectSensorDataする必要があります。これらのメソッドは、 ISensors.hal仕様のバージョン2.1で追加された新しいタイプを使用するためです。
サブHALは、マルチHALがバージョン2.1サブHALとして扱うために、 sensorsHalGetSubHal_2_1ではなくsensorsHalGetSubHalを公開する必要があります。

センサーHAL2.0からの移植

Sensors HAL2.0からSensorsMulti-HAL 2.0にアップグレードする場合は、HALの実装が次の要件を満たしていることを確認してください。

HALの初期化

センサーHAL2.0には、センサーサービスがFMQと動的センサーコールバックを渡すことを可能にする初期化機能があります。 Sensors Multi-HAL 2.0では、 initialize()関数は、センサーイベントの送信、ウェイクロックの取得、動的センサーの接続と切断の通知に使用する必要がある単一のコールバックを渡します。

Multi-HAL実装へのセンサーイベントの投稿

FMQを介してセンサーイベントを送信する代わりに、サブHALは、センサーイベントが使用可能な場合、センサーイベントをIHalProxyCallbackに書き込む必要があります。

WAKE_UPイベント

Sensors HAL 2.0では、HALはその実装のためにウェイクロックを管理できます。 Sensors Multi-HAL 2.0では、サブHALを使用すると、Multi-HAL実装でウェイクロックを管理でき、 createScopedWakelockを呼び出すことでウェイクロックの取得を要求できます。ウェイクアップイベントをMulti-HAL実装に投稿するときは、ロックされたスコープのウェイクロックを取得してpostEventsに渡す必要があります。

動的センサー

Sensors Multi-HAL 2.0では、動的センサー接続が変更されるたびに、 IHalProxyCallbackのonDynamicSensorsConnectedとonDynamicSensorsDisconnectedが呼び出される必要があります。これらのコールバックは、 initialize()関数を介して提供されるIHalProxyCallbackポインターの一部として使用できます。

センサーHAL1.0からの移植

Sensors HAL1.0からSensorsMulti-HAL 2.0にアップグレードする場合は、HALの実装が次の要件を満たしていることを確認してください。

HALの初期化

サブHALとマルチHAL実装の間のコールバックを確立するには、 initialize()関数をサポートする必要があります。

利用可能なセンサーの公開

Sensors Multi-HAL 2.0では、 getSensorsList()関数は、センサーHALが再起動した場合でも、単一のデバイスの起動中に同じ値を返す必要があります。これにより、システムサーバーが再起動した場合に、フレームワークがセンサー接続の再確立を試みることができます。 getSensorsList()によって返される値は、デバイスが再起動を実行した後に変更される可能性があります。

Multi-HAL実装へのセンサーイベントの投稿

Sensors HAL 2.0では、 poll()が呼び出されるのを待つ代わりに、サブHALは、センサーイベントが使用可能になるたびに、センサーイベントをIHalProxyCallbackにプロアクティブに書き込む必要があります。

WAKE_UPイベント

Sensors HAL 1.0では、HALはその実装のためにウェイクロックを管理できます。 Sensors Multi-HAL 2.0では、サブHALを使用すると、Multi-HAL実装でウェイクロックを管理でき、 createScopedWakelockを呼び出すことでウェイクロックの取得を要求できます。ウェイクアップイベントをMulti-HAL実装に投稿するときは、ロックされたスコープのウェイクロックを取得してpostEventsに渡す必要があります。

動的センサー

Sensors HAL 1.0では、動的センサーはpoll()関数を介して返されます。 Sensors Multi-HAL 2.0では、動的センサー接続が変更されるたびに、 IHalProxyCallbackのonDynamicSensorsConnectedとonDynamicSensorsDisconnectedが呼び出される必要があります。これらのコールバックは、 initialize()関数を介して提供されるIHalProxyCallbackポインターの一部として使用できます。

センサーからの移植Multi-HAL1.0

Sensors Multi-HAL 1.0から既存の実装を移植するには、次の手順に従います。

センサーのHAL構成が/vendor/etc/sensors/hals.conf.これには、 /system/etc/sensors/hals.confにあるファイルの移動が含まれる場合があります。
これらはHAL2.0でサポートされていないため、hardware /hardware.hおよびhardware/hardware.h hardware/sensors.hへの参照をすべて削除します。
センサーHal1.0からの移植で説明されているようにサブHALを移植します。
Sensors Mutli-HAL 2.0の実装セクションの手順3と4に従って、Sensors Multi-HAL2.0を指定されたHALとして設定します。

検証

VTSの実行

1つ以上のサブHALをSensorsMulti-Hal 2.1と統合した場合は、ベンダーテストスイート（VTS）を使用して、サブHALの実装がSensorsHALインターフェイスによって設定されたすべての要件を満たしていることを確認します。

VTSがホストマシンにセットアップされているときにセンサーVTSテストのみを実行するには、次のコマンドを実行します。

vts-tradefed run commandAndExit vts \
    --skip-all-system-status-check \
    --primary-abi-only \
    --skip-preconditions \
    --module VtsHalSensorsV2_0Target && \
  vts-tradefed run commandAndExit vts \
    --skip-all-system-status-check \
    --primary-abi-only \
    --skip-preconditions \
    --module VtsHalSensorsV2_1Target

単体テストの実行

HalProxyの単体テストは、単体テストでインスタンス化され、動的にロードされない偽のサブHALを使用してHalProxy_test.cppをテストします。新しいサブHALを作成する場合、これらのテストは、新しいサブHALが正しく実装されていることを確認する単体テストを追加する方法のガイドとして機能する必要があります。

テストを実行するには、次のコマンドを実行します。

cd $ANDROID_BUILD_TOP/hardware/interfaces/sensors/common/default/2.X/multihal/tests
atest

偽のサブHALを使用したテスト

偽のサブHALは、 ISensorsSubHalインターフェイスのダミー実装です。サブHALは、センサーのさまざまなリストを公開します。センサーがアクティブ化されると、特定のセンサー要求で指定された間隔に基づいて、自動的に生成されたセンサーイベントをHalProxyに定期的に送信します。

偽のサブHALを使用して、完全なマルチHALコードがシステムにロードされた他のサブHALとどのように連携するかをテストし、センサーマルチHALコードのさまざまな側面にストレスをかけることができます。

2つの偽のサブHALは、 hardware/interfaces/sensors/common/default/2.X/multihal/tests/fake_subhal/で入手できます。

偽のサブHALをビルドしてデバイスにプッシュするには、次の手順を実行します。

次のコマンドを実行して、3つの異なる偽のサブHALをビルドしてデバイスにプッシュします。

$ANDROID_BUILD_TOP/hardware/interfaces/sensors/common/default/2.X/multihal/tests/
mma
adb push \
  $ANDROID_BUILD_TOP/out/target/product/<device>/symbols/vendor/lib64/android.hardware.sensors@2.X-fakesubhal-config1.so \
  /vendor/lib64/android.hardware.sensors@2.X-fakesubhal-config1.so
adb push \
  $ANDROID_BUILD_TOP/out/target/product/<device>/symbols/vendor/lib64/android.hardware.sensors@2.X-fakesubhal-config2.so \
  /vendor/lib64/android.hardware.sensors@2.X-fakesubhal-config2.so
adb push \
  $ANDROID_BUILD_TOP/out/target/product/<device>/symbols/vendor/lib64/android.hardware.sensors@2.X-fakesubhal-config3.so \
  /vendor/lib64/android.hardware.sensors@2.X-fakesubhal-config3.so

/vendor/etc/sensors/hals.confにあるセンサーHAL構成を、偽のサブHALのパスで更新します。

/vendor/lib64/android.hardware.sensors@2.X-fakesubhal-config1.so
/vendor/lib64/android.hardware.sensors@2.X-fakesubhal-config2.so
/vendor/lib64/android.hardware.sensors@2.X-fakesubhal-config3.so

HalProxyを再起動し、構成にリストされている新しいサブHALをロードします。
```
adb shell stop
adb shell start
```

デバッグ

開発者は、 lshalコマンドを使用してフレームワークをデバッグできます。 Sensors HALのデバッグ出力を要求するには、次のコマンドを実行します。

adb root
adb shell lshal debug android.hardware.sensors@2.1::ISensors/default

次に、 HalProxyとそのサブHALの現在の状態に関する情報が端末に出力されます。以下に示すのは、 HalProxyオブジェクトと偽のサブHALのコマンド出力の例です。

Internal values:
  Threads are running: true
  Wakelock timeout start time: 200 ms ago
  Wakelock timeout reset time: 73208 ms ago
  Wakelock ref count: 0
  # of events on pending write queue: 0
  # of non-dynamic sensors across all subhals: 8
  # of dynamic sensors across all subhals: 0
SubHals (2):
  Name: FakeSubHal-OnChange
  Debug dump:
Available sensors:
Name: Ambient Temp Sensor
Min delay: 40000
Flags: 2
Name: Light Sensor
Min delay: 200000
Flags: 2
Name: Proximity Sensor
Min delay: 200000
Flags: 3
Name: Relative Humidity Sensor
Min delay: 40000
Flags: 2
  Name: FakeSubHal-OnChange
  Debug dump:
Available sensors:
Name: Ambient Temp Sensor
Min delay: 40000
Flags: 2
Name: Light Sensor
Min delay: 200000
Flags: 2
Name: Proximity Sensor
Min delay: 200000
Flags: 3
Name: Relative Humidity Sensor
Min delay: 40000
Flags: 2

# of events on pending write queue数に指定された数が大きい場合（1000以上）、センサーフレームワークへの書き込みが保留されているイベントが多数あることを示します。これは、センサーサービスがデッドロックされているか、クラッシュしてセンサーイベントを処理していないか、センサーイベントの大規模なバッチがサブHALから最近投稿されたことを示します。

ウェイクロック参照カウントが0より大きい場合、これはHalProxyがウェイクロックを取得したことを意味します。これは、 ScopedWakelockが意図的に保持されている場合、またはウェイクアップイベントがHalProxyに送信され、センサーフレームワークによって処理されていない場合にのみ、 0より大きくする必要があります。

HalProxyのデバッグメソッドに渡されるファイル記述子は各サブHALに渡されるため、開発者はISensorsSubHalインターフェイスの一部としてデバッグメソッドを実装する必要があります。