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

實施健康 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 （儘管是系統守護進程）。 IHealth被添加到系統清單中，實例名稱為“backup”。
框架和storaged通過hwbinder而不是binder與healthd通信。
框架和storaged的代碼被更改為獲取實例“默認”（如果可用），然後是“備份”。
- C++ 客戶端代碼使用libhealthhalutils中定義的邏輯。
- Java 客戶端代碼使用HealthServiceWrapper中定義的邏輯。
在 IHealth/default 廣泛可用且 Android 8.1 供應商映像被棄用後，可以棄用 IHealth/backup 和healthd 。有關更多詳細信息，請參閱棄用 health@1.0 。

healthd 的特定於板的構建變量

BOARD_PERIODIC_CHORES_INTERVAL_*是用於構建healthd的特定於板的變量。作為系統/供應商構建拆分的一部分，無法為系統模塊定義特定於板的值。在 health@2.0 中，供應商可以在healthd_mode_ops->init中覆蓋這兩個值（通過在health@2.0-service.<device>中刪除libhealthservice依賴並重新實現此功能）。

靜態實現庫

與其他 HAL 實現庫不同，實現庫 health@2.0-impl 是一個靜態庫，health@2.0-service、charger、recovery 和 legacy healthd 鏈接到該庫。

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、charger 和healthd之間的其餘公共代碼，並調用 IHealth 方法而不是 BatteryMonitor。

實施健康 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 權限。

通過將直通實現安裝到恢復映像，在恢復中實現 HAL。例子：

// 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 。

健康客戶

有關健康 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通過 binder 調用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.

內核接口

請參閱運行狀況 2.1 HAL 的內核接口。

測試

Android 9 包含專門為 health@2.0 HAL 編寫的新VTS 測試。如果設備在設備清單中聲明提供 health@2.0 HAL，則它必須通過相應的 VTS 測試。為默認實例（以確保設備正確實現 HAL）和備份實例（以確保healthd在被刪除之前繼續正常運行）編寫測試。

電池信息要求

請參閱電池信息要求。