實作健康狀態 2.1

在 Android 11 中，所有 healthd 程式碼都會重構為 接著 libhealthloop 和 libhealth2impl，然後修改為實作 health@2.1 HAL。這兩個程式庫是透過 health@2.0-impl-2.1 以靜態方式連結， 直通式實作 Health 2.1靜態連結程式庫 讓 health@2.0-impl-2.1 執行與 healthd 相同的工作，例如執行 healthd_mainloop和意見調查。在 init 中，health@2.1-service 會註冊 將 IHealth 介面實作為 hwservicemanager。升級時 搭載 Android 8.x 或 9 的裝置 以及 Android 11 架構 廠商映像檔可能未提供 health@2.1 服務，向後 Google Cloud 修訂 淘汰時間表。

為確保回溯相容性：

  1. healthd儘管系統是系統，IHealth仍註冊為hwservicemanager Daemon系統會將 IHealth 新增至系統資訊清單，其中包含執行個體名稱 「backup」
  2. 架構和 storaged 會透過 hwbinder 與 healthd 通訊 而不是 binder。
  3. 架構和 storaged 的程式碼已變更以擷取執行個體 「預設」如果可以，則請設為「備份」。
    • C++ 用戶端程式碼使用 libhealthhalutils 中定義的邏輯。
    • Java 用戶端程式碼會使用 HealthServiceWrapper 中定義的邏輯。
  4. 廣泛開放使用 IHealth/default 且 Android 8.1 廠商映像檔後 已淘汰 IHealth/備份和 healthd。如要 詳細資料，請參閱 淘汰 health@1.0。

適用於 Healthd 的板型特定建構變數

BOARD_PERIODIC_CHORES_INTERVAL_* 是主機專用變數，用於建構 healthd。做為系統/廠商建構分割的一部分，主機專屬值 定義系統模組。要覆寫的這些值 已淘汰的函式 healthd_board_init 中。

在 health@2.1 中，供應商可以覆寫 healthd_config 結構體中的這兩個週期性工作間隔值， 傳遞至健康狀態實作類別建構函式。健康 實作類別應繼承自 android::hardware::health::V2_1::implementation::Health。

實作 Health 2.1 服務

如要瞭解如何實作 Health 2.1 服務，請參閱 hardware/interfaces/health/2.1/README.md。

醫療保健客戶

health@2.x 擁有下列用戶端：

  • 充電器。libbatterymonitor 和 healthd_common 程式碼的使用 已納入 health@2.0-impl。
  • 復原程序libbatterymonitor 的連結已納入 health@2.0-impl。所有傳送至 BatteryMonitor 的呼叫都會替換為 Health 實作類別。

  • BatteryManager。是唯一的BatteryManager.queryProperty(int id) 「IBatteryPropertiesRegistrar.getProperty」用戶端。 「IBatteryPropertiesRegistrar.getProperty」是由以下公司提供： healthd 並直接讀取 /sys/class/power_supply。

    基於安全考量，應用程式不得呼叫健康 HAL 在 Android 9 以上版本中，繫結器 「IBatteryPropertiesRegistrar」服務是由「BatteryService」提供 而不是 healthd。BatteryService 會委派呼叫給健康狀態 HAL 擷取所要求的資訊。

  • BatteryService。在 Android 9 以上版本中 BatteryService 會使用 HealthServiceWrapper 判斷是否要使用 「default」健康狀態服務執行個體 (來自 vendor)，或使用備份 來自 healthd 的健康服務執行個體。BatteryService之後會收聽 健康事件持續至 IHealth.registerCallback。

  • 已保存。在 Android 9 以上版本中 storaged 會使用 libhealthhalutils 判斷是否要使用 「default」健康狀態服務執行個體 (來自 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 Daemon 和預設實作 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 (已新增至 Health 2.1)
  • /sys/class/power_supply/*/type
  • /sys/class/power_supply/*/voltage_max
  • /sys/class/power_supply/*/voltage_now

使用 libbatterymonitor 的任何裝置專屬健康 HAL 實作 預設存取這些核心介面，除非在健康狀態中覆寫設定 實作類別建構函式。

如果檔案遺失，或無法透過 healthd 或 預設服務 (例如，檔案是供應商專屬資料夾的符號連結) 會因為 SELinux 政策設定錯誤而拒絕存取)， 功能。因此，某些供應商專屬的 SELinux 變更可能會 以便進行這項作業

Health 2.1 中使用的部分核心介面，例如 「/sys/class/power_supply/*/capacity_level」和 /sys/class/power_supply/*/time_to_full_now，不一定是選填項目。不過， 可防止因缺少核心介面而產生不正確的架構行為。 建議選擇 智利 1398913 再建構 Health HAL 2.1 服務

測試

Android 11 內含 VTS 測試 特別針對 health@2.1 HAL 撰寫如果裝置宣告 裝置資訊清單中的 health@2.1 HAL 通過相應的 VTS 測試。 系統會針對預設執行個體寫入測試 (為確保裝置 正確實作 HAL) 和備份執行個體 (確保healthd 在移除前仍可繼續正常運作)。

電池資訊規定

Health 2.0 HAL 在 HAL 介面上指出了一組要求，但 相應的 VTS 測試在強制執行時相對放鬆。 Android 11 新增了 VTS 測試，以強制執行 下列規定： 11 以及更高版本：

  • 即時和平均電池電流的單位必須為微安 (μA)。
  • 必須立即提供正確的瞬間和平均電池電流。 詳細說明：
    • 目前電量為 UNKNOWN 時 == 0
    • 目前 >電池狀態為「CHARGING」時為 0
    • 目前電池狀態為 NOT_CHARGING 時 <= 0
    • 目前<電池狀態為「DISCHARGING」時為 0
    • 電池狀態為「FULL」時未強制執行
  • 電池狀態必須準確反映電源狀態 已連線。詳細說明：
    • 電池狀態必須是 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 電源供應器類別。