Implementa Health 2.0

Todo el código de healthd se refactorizó en health@2.0-impl y libhealthservice, y luego se modificó para implementar el HAL de health@2.0. Estas dos bibliotecas están vinculadas de forma estática por health@2.0-service, lo que le permite realizar el trabajo que antes realizaba healthd (es decir, ejecutar healthd_mainloop y realizar sondeos). En init, health@2.0-service registra una implementación de la interfaz IHealth en hwservicemanager. Cuando se actualizan dispositivos con una imagen de proveedor de Android 8.x y un framework de Android 9, es posible que la imagen del proveedor no proporcione el servicio health@2.0. Esto se aplica con el programa de baja.

Para solucionar este problema, sigue estos pasos:

  1. healthd registra IHealth en hwservicemanager (a pesar de ser un daemon del sistema). IHealth se agrega al manifiesto del sistema, con el nombre de instancia "backup".
  2. El framework y storaged se comunican con healthd a través de hwbinder en lugar de binder.
  3. El código del framework y storaged se cambia para recuperar la instancia "default" si está disponible y, luego, "backup".
    • El código cliente C++ usa la lógica definida en libhealthhalutils.
    • El código cliente de Java usa la lógica definida en HealthServiceWrapper.
  4. Una vez que IHealth/default esté disponible de forma general y las imágenes del proveedor de Android 8.1 dejen de estar disponibles, IHealth/backup y healthd pueden dejar de estar disponibles. Para obtener más detalles, consulta health@1.0 dejó de estar disponible.

Variables de compilación específicas de la placa para healthd

BOARD_PERIODIC_CHORES_INTERVAL_* son variables específicas de la placa que se usan para compilar healthd. Como parte de la división de compilación entre sistemas y proveedores, no se pueden definir los valores específicos de la placa para los módulos del sistema. En health@2.0, los proveedores pueden anular estos dos valores en healthd_mode_ops->init (si descartan la dependencia libhealthservice en health@2.0-service.<device> y vuelven a implementar esta función).

Biblioteca de implementación estática

A diferencia de otras bibliotecas de implementación de HAL, la biblioteca de implementación health@2.0-impl es una biblioteca estática a la que se vinculan health@2.0-service, el cargador, la recuperación y el healthd heredado.

health@2.0.impl implementa IHealth como se describió anteriormente y está diseñado para unir libbatterymonitor y libhealthd.BOARD. Estos usuarios de health@2.0-impl no deben usar BatteryMonitor ni las funciones de libhealthd directamente. En su lugar, estas llamadas deben reemplazarse por llamadas a la clase Health, una implementación de la interfaz IHealth. Para generalizar aún más, el código healthd_common también se incluye en health@2.0-impl. El nuevo healthd_common contiene el resto del código común entre health@2.0-service, el cargador y healthd, y llama a los métodos de IHealth en lugar de BatteryMonitor.

Implementa el servicio de Health 2.0

Cuando implementes el servicio de health@2.0 para un dispositivo, si la implementación predeterminada es la siguiente:

  • Es suficiente para el dispositivo, usa android.hardware.health@2.0-service directamente.

  • No es suficiente para el dispositivo, crea el ejecutable android.hardware.health@2.0-service.(device) y, luego, incluye lo siguiente:

    #include <health2/service.h>
int main() { return health_service_main(); }

Luego:

  • Si es libhealthd: específico de la tabla

    • Existe, tiene un vínculo a ella.
    • No existe, proporciona implementaciones vacías para las funciones healthd_board_init y healthd_board_battery_update.

  • Si las variables BOARD_PERIODIC_CHORES_INTERVAL_* específicas de la placa son las siguientes:

    • Están definidos, crean un HealthServiceCommon.cpp específico del dispositivo (copiado de hardware/interfaces/health/2.0/utils/libhealthservice) y personalízalo en healthd_mode_service_2_0_init.
    • No están definidos. Crea un vínculo a libhealthservice de forma estática.

  • Si el dispositivo:

    • Si debes implementar las APIs de getStorageInfo y getDiskStats, proporciona la implementación en las funciones get_storage_info y get_disk_stats.
    • No deberías implementar esas APIs, vincular a libstoragehealthdefault de forma estática.

  • Actualiza los permisos necesarios de SELinux.

  • Para implementar HAL en la recuperación, instala una implementación de transferencia a la imagen de recuperación. Ejemplo:

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

Para obtener más información, consulta hardware/interfaces/health/2.0/README.md.

Clientes de Health

Consulta Clientes de Health para la HAL de Health 2.1.

Cambios de SELinux

El nuevo HAL de health@2.0 incluye los siguientes cambios de SELinux:

  • Se agregó health@2.0-service a file_contexts.
  • Permite que system_server y storaged usen hal_health.
  • Permite que system_server (BatteryService) registre batteryproperties_service (IBatteryPropertiesRegistrar).
  • Permite que healthd proporcione hal_health.
  • Quita las reglas que permiten que system_server y storaged llamen a healthd a través de Binder.
  • Quita las reglas que permiten que healthd registre batteryproperties_service (IBatteryPropertiesRegistrar).

En el caso de los dispositivos con su propia implementación, es posible que se deban realizar algunos cambios en SELinux del proveedor. Ejemplo:

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

Interfaces del kernel

Consulta Interfaz de kernel para la HAL de Health 2.1.

Prueba

Android 9 incluye nuevas pruebas de VTS escritas específicamente para el HAL de health@2.0. Si un dispositivo declara proporcionar una HAL de health@2.0 en el manifiesto del dispositivo, debe pasar las pruebas de VTS correspondientes. Las pruebas se escriben para la instancia predeterminada (para garantizar que el dispositivo implemente el HAL correctamente) y la instancia de copia de seguridad (para garantizar que healthd siga funcionando correctamente antes de que se quite).

Requisitos de información de la batería

Consulta los requisitos de información de la batería.