本頁面由 Cloud Translation API 翻譯而成。

實作 Health 2.0

所有 healthd 程式碼皆已重構為 health@2.0-impl 並 libhealthservice，然後修改為實作 health@2.0 HAL。這兩個透過 health@2.0-service 靜態連結程式庫，先前由 healthd 完成的工作 (也就是執行 healthd_mainloop，然後輪詢)。在 init 中，health@2.0-service 會註冊 IHealth 到 hwservicemanager 的介面。如果使用 Android 8.x 供應商圖片和 Android 9 架構供應商映像檔可能未提供 health@2.0 服務。這是強制執行由淘汰時間表。

如何解決此問題：

healthd 會將 IHealth 註冊到 hwservicemanager (儘管是系統) Daemon)。系統會將 IHealth 新增至系統資訊清單，並附帶執行個體名稱 "backup"。
架構和 storaged 透過 hwbinder 與 healthd 通訊而不是 binder。
架構和 storaged 的程式碼已變更為擷取執行個體 "default" (如果有的話)，之後為 "backup"。
- C++ 用戶端程式碼使用 libhealthhalutils 中定義的邏輯。
- Java 用戶端程式碼會使用 HealthServiceWrapper 中定義的邏輯。
廣泛開放使用 IHealth/default 且 Android 8.1 廠商映像檔後已淘汰 IHealth/備份和 healthd。如要詳情請參閱 Deprecating health@1.0。

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

BOARD_PERIODIC_CHORES_INTERVAL_* 是主機專用變數，用於建構 healthd。做為系統/供應商版本分割的一部分，董事會專屬值定義系統模組。在 health@2.0 中，供應商可以覆寫 healthd_mode_ops->init 中的這兩個值 (方法是捨棄 libhealthservice health@2.0-service.<device> 中的依附元件，並重新實作這個函式)。

靜態實作程式庫

與其他 HAL 實作程式庫不同，實作程式庫 health@2.0-impl 是一個靜態程式庫，專門用於 Health@2.0-service、Charge 以及舊版健康狀態連結

health@2.0.impl 導入上述 IHealth 來當做包裝， libbatterymonitor和libhealthd.BOARD前後。這些 Health@2.0-impl 的使用者不得使用 BatteryMonitor 或 libhealthd；而是應以 Health 類別，這是 IHealth 介面的實作。一般化，healthd_common 程式碼也包含在 health@2.0-impl 中。而 healthd_common 包含 health@2.0-service、充電器，healthd，並呼叫 IHealth 方法，而不是 BatteryMonitor。

實作 Health 2.0 服務

為裝置實作 Health@2.0 服務時 (若為預設實作) 為：

足夠的裝置資訊，請使用 android.hardware.health@2.0-service
裝置不足，無法 android.hardware.health@2.0-service.(device) 執行檔，包括：
```
#include <health2/service.h>
int main() { return health_service_main(); }
```

然後執行下列步驟：

針對董事會特定 libhealthd:
- 已存在，請連結至該名稱。
- 不存在，為 healthd_board_init 提供空白實作和 healthd_board_battery_update 函式
如果主機專用的 BOARD_PERIODIC_CHORES_INTERVAL_* 變數：
- 已定義，建立裝置專用的 HealthServiceCommon.cpp (複製而來) 出發地：hardware/interfaces/health/2.0/utils/libhealthservice) 和自訂 healthd_mode_service_2_0_init。
- 未定義，請靜態連結至「libhealthservice」。
如果是裝置：
- 應實作 getStorageInfo 和 getDiskStats API 時，請提供 get_storage_info 和 get_disk_stats 函式中的實作。
- 不要實作這些 API，請連結至 libstoragehealthdefault
更新必要的 SELinux 權限。

安裝直通式實作至復原映像檔例子：

// Android.bp
cc_library_shared {
    name: "android.hardware.health@2.0-impl-<device>",
    recovery_available: true,
    relative_install_path: "hw",
    static_libs: [
        "android.hardware.health@2.0-impl",
        "libhealthd.<device>"
        // Include the following or implement device-specific storage APIs
        "libhealthstoragedefault",
    ],
    srcs: [
        "HealthImpl.cpp",
    ],
    overrides: [
        "android.hardware.health@2.0-impl-default",
    ],
}

// HealthImpl.cpp
#include <health2/Health.h>
#include <healthd/healthd.h>
using android::hardware::health::V2_0::IHealth;
using android::hardware::health::V2_0::implementation::Health;
extern "C" IHealth* HIDL_FETCH_IHealth(const char* name) {
    const static std::string providedInstance{"default"};
    if (providedInstance != name) return nullptr;
    return Health::initInstance(&gHealthdConfig).get();
}

# device.mk
PRODUCT_PACKAGES += android.hardware.health@2.0-impl-<device>

詳情請參閱 hardware/interfaces/health/2.0/README.md。

醫療保健客戶

請參閱「Health 用戶端 for Health 2.1 HAL」。

SELinux 變更

新的 health@2.0 HAL 包含下列 SELinux 變更：

將 health@2.0-service 新增至 file_contexts。
允許 system_server 和 storaged 使用 hal_health。
允許 system_server (BatteryService) 註冊 batteryproperties_service (IBatteryPropertiesRegistrar)。
允許 healthd 提供 hal_health。
移除允許 system_server 和 storaged 進行呼叫的規則 healthd 透過繫結器。
移除允許 healthd 註冊 batteryproperties_service 的規則 (IBatteryPropertiesRegistrar)。

對於自行實作的裝置，某些廠商 SELinux 的變更可能會無從得知例子：

# device/<manufacturer>/<device>/sepolicy/vendor/file_contexts
/vendor/bin/hw/android\.hardware\.health@2\.0-service.<device> u:object_r:hal_health_default_exec:s0

# 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.

核心介面

請參閱 Health 2.1 HAL 的核心介面。

測試

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

電池資訊規定

請參閱「電池資訊需求」。