Android 11では、すべてのhealthd
コードがlibhealthloop
とlibhealth2impl
にリファクタリングされ、health @ 2.1HALを実装するように変更されます。これらの2つのライブラリは、 health@2.0-impl-2.1
のパススルー実装であるhealth@2.0-impl-2.1によって静的にリンクされています。静的にリンクされたライブラリにより、health @ 2.0- healthd
healthd_mainloop
health@2.0-impl-2.1
作業を実行できます。 initでは、health @ 2.1- hwservicemanager
がインターフェースIHealth
の実装をhealth@2.1-service
に登録します。 Android8.xまたは9ベンダーイメージとAndroid11フレームワークを備えたデバイスをアップグレードする場合、ベンダーイメージがhealth@2.1サービスを提供しない場合があります。古いベンダーイメージとの下位互換性は、非推奨スケジュールによって強制されます。
下位互換性を確保するには:
-
healthd
は、システムデーモンであるにもかかわらず、IHealth
をhwservicemanager
に登録します。IHealth
は、インスタンス名「backup」でシステムマニフェストに追加されます。 - フレームワークと
hwbinder
は、binder
の代わりにhealthd
を介してstoraged
と通信します。 - フレームワークと
storaged
のコードは、インスタンスが利用可能な場合は「デフォルト」をフェッチし、次に「バックアップ」をフェッチするように変更されています。- C ++クライアントコードは、
libhealthhalutils
で定義されたロジックを使用します。 - Javaクライアントコードは、
HealthServiceWrapper
で定義されたロジックを使用します。
- C ++クライアントコードは、
- IHealth / defaultが広く利用可能になり、Android 8.1ベンダーのイメージが非推奨になった後、IHealth / backupと
healthd
を非推奨にすることができます。詳細については、 health @ 1.0の廃止を参照してください。
healthdのボード固有のビルド変数
BOARD_PERIODIC_CHORES_INTERVAL_*
は、 healthd
を構築するために使用されるボード固有の変数です。システム/ベンダービルド分割の一部として、ボード固有の値をシステムモジュールに定義することはできません。これらの値は、非推奨の関数healthd_board_init
でオーバーライドされていました。
health@2.1では、ベンダーは、health実装クラスコンストラクターに渡す前に、 healthd_config
構造体のこれら2つの定期的な雑用間隔の値をオーバーライドできます。ヘルス実装クラスは、 android::hardware::health::V2_1::implementation::Health
から継承する必要があります。
Health2.1サービスの実装
Health 2.1サービスの実装については、 hardware / interfaces / health / 2.1 /README.mdを参照してください。
健康クライアント
health@2.xには次のクライアントがあります。
- 充電器。
libbatterymonitor
とhealthd_common
コードの使用は、health @ 2.0-implでラップされてhealth@2.0-impl
。 - 回復。 libbatterymonitorへのリンクは
libbatterymonitor
でラップされてhealth@2.0-impl
。BatteryMonitor
へのすべての呼び出しは、Health
実装クラスへの呼び出しに置き換えられます。 BatteryManager 。
BatteryManager.queryProperty(int id)
は、IBatteryPropertiesRegistrar.getProperty
の唯一のクライアントでした。IBatteryPropertiesRegistrar.getProperty
は、healthdによって提供され、/sys/class/power_supply
healthd
直接読み取りました。セキュリティ上の考慮事項として、アプリがヘルスHALに直接呼び出すことは許可されていません。 Android 9以降では、バインダーサービス
IBatteryPropertiesRegistrar
はBatteryService
ではなくhealthd
によって提供されます。BatteryService
は、要求された情報を取得するためにヘルスHALへの呼び出しを委任します。BatteryService 。 Android 9以降では、
BatteryService
はHealthServiceWrapper
を使用して、vendor
のデフォルトのヘルスサービスインスタンスを使用するか、healthd
のバックアップヘルスサービスインスタンスを使用するかを決定します。次に、BatteryService
はIHealth.registerCallback
を介してヘルスイベントをリッスンします。ストレージ。 Android 9以降では、
storaged
はlibhealthhalutils
を使用して、vendor
のデフォルトのヘルスサービスインスタンスを使用するか、healthd
のバックアップヘルスサービスインスタンスを使用するかを決定します。次に、storaged
はIHealth.registerCallback
を介してヘルスイベントをリッスンし、ストレージ情報を取得します。
SELinuxの変更
health@2.1 HALには、プラットフォームに次のSELinuxの変更が含まれています。
-
android.hardware.health@2.1-service
をfile_contexts
に追加します。
独自の実装を持つデバイスの場合、ベンダーのSELinuxの変更が必要になる場合があります。例:
# device/<manufacturer>/<device>/sepolicy/vendor/hal_health_default.te
# Add device specific permissions to hal_health_default domain, especially
# if it links to board-specific libhealthd or implements storage APIs.
カーネルインターフェース
healthd
デーモンとデフォルトの実装android.hardware.health@2.0-impl-2.1
は、次のカーネルインターフェイスにアクセスして、バッテリー情報を取得します。
-
/sys/class/power_supply/*/capacity_level
(health 2.1に追加) -
/sys/class/power_supply/*/capacity
-
/sys/class/power_supply/*/charge_counter
-
/sys/class/power_supply/*/charge_full
-
/sys/class/power_supply/*/charge_full_design
(health 2.1に追加) -
/sys/class/power_supply/*/current_avg
-
/sys/class/power_supply/*/current_max
-
/sys/class/power_supply/*/current_now
-
/sys/class/power_supply/*/cycle_count
-
/sys/class/power_supply/*/health
-
/sys/class/power_supply/*/online
-
/sys/class/power_supply/*/present
-
/sys/class/power_supply/*/status
-
/sys/class/power_supply/*/technology
-
/sys/class/power_supply/*/temp
-
/sys/class/power_supply/*/time_to_full_now
(ヘルス2.1に追加) -
/sys/class/power_supply/*/type
-
/sys/class/power_supply/*/voltage_max
-
/sys/class/power_supply/*/voltage_now
libbatterymonitor
を使用するデバイス固有のヘルスHAL実装は、ヘルス実装クラスコンストラクターでオーバーライドされない限り、デフォルトでこれらのカーネルインターフェイスにアクセスします。
これらのファイルが見つからないか、 healthd
またはデフォルトサービスからアクセスできない場合(たとえば、ファイルが、SELinuxポリシーが正しく構成されていないためにアクセスを拒否するベンダー固有のフォルダーへのシンボリックリンクである場合)、正しく機能しない可能性があります。したがって、デフォルトの実装が使用されている場合でも、ベンダー固有のSELinuxの追加の変更が必要になる場合があります。
/sys/class/power_supply/*/capacity_level
や/sys/class/power_supply/*/time_to_full_now
など、Health2.1で使用される一部のカーネルインターフェイスはオプションの場合があります。ただし、カーネルインターフェイスの欠落に起因する誤ったフレームワークの動作を防ぐために、ヘルスHAL2.1サービスを構築する前にCL1398913を選択することをお勧めします。
テスト
Android 11には、health @ 2.1HAL用に特別に作成された新しいVTSテストが含まれています。デバイスがデバイスマニフェストでhealth@2.1 HALを宣言する場合、対応するVTSテストに合格する必要があります。テストは、デフォルトインスタンス(デバイスがHALを正しく実装していることを確認するため)とバックアップインスタンス( healthd
が削除される前に正しく機能し続けることを確認するため)の両方に対して作成されます。
バッテリー情報の要件
health 2.0 HALは、HALインターフェイスに関する一連の要件を示していますが、対応するVTSテストは、それらを適用する際に比較的緩和されています。 Android 11では、Android 11以降で起動するデバイスに次の要件を適用するために、新しいVTSテストが追加されています。
- 瞬時および平均バッテリ電流の単位は、マイクロアンペア(μA)である必要があります。
- 瞬時および平均バッテリ電流の符号は正しくなければなりません。具体的には:
- current == 0(バッテリーの状態が
UNKNOWN
の場合) - バッテリーステータスが
CHARGING
の場合、電流> 0 - バッテリーステータスが
NOT_CHARGING
の場合、current <= 0 - バッテリーステータスが
DISCHARGING
の場合、電流<0 - バッテリーステータスが
FULL
の場合は強制されません
- current == 0(バッテリーの状態が
- バッテリーの状態は、電源が接続されているかどうかに対して正しい必要があります。具体的には:
- バッテリステータスは、電源が接続されている場合に限り、
CHARGING
、NOT_CHARGING
、またはFULL
のいずれかである必要があります。 - 電源が切断されている場合に限り、
DISCHARGING
の状態は放電している必要があります。
- バッテリステータスは、電源が接続されている場合に限り、
実装でlibbatterymonitor
を使用し、カーネルインターフェイスから値を渡す場合は、sysfsノードが正しい値を報告していることを確認してください。
- バッテリー電流が正しい記号と単位で報告されていることを確認してください。これには、次のsysfsノードが含まれます。
-
/sys/class/power_supply/*/current_avg
-
/sys/class/power_supply/*/current_max
-
/sys/class/power_supply/*/current_now
- 正の値は、バッテリーへの入力電流を示します。
- 値はマイクロアンペア(μA)である必要があります。
-
- バッテリー電圧がマイクロボルト(μV)で報告されていることを確認してください。これには、次のsysfsノードが含まれます。
-
/sys/class/power_supply/*/voltage_max
-
/sys/class/power_supply/*/voltage_now
- デフォルトのHAL実装は、
voltage_now
を1000で除算し、ミリボルト(mV)で値を報告することに注意してください。 @ 1.0 :: HealthInfoを参照してください。
-
詳細については、 Linux電源クラスを参照してください。