Implementa Health 2.0

Todo el código healthd se refactorizó a health@2.0-impl y libhealthservice y, luego, se modificó para implementar la HAL de health@2.0. Estos dos las bibliotecas están vinculadas estáticamente a health@2.0-service, lo que le permite realizar trabajo que antes realizaba healthd (es decir, ejecutar healthd_mainloop y realizar sondeos). En init, health@2.0-service registra una implementación del interfaz IHealth a hwservicemanager. Si actualizas dispositivos con un Imagen del 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 de manera forzosa por el cronograma de baja.

Para solucionar este problema, sigue estos pasos:

  1. healthd registra IHealth en hwservicemanager (a pesar de ser un sistema daemon). Se agrega IHealth al manifiesto del sistema, con el nombre de la instancia. "backup"
  2. El framework y storaged se comunican con healthd a través de hwbinder. en lugar de binder.
  3. Se cambió el código del framework y storaged para recuperar la instancia "default" si está disponible, entonces "backup".
    • El código del cliente C++ usa la lógica definida en libhealthhalutils.
    • El código de cliente de Java usa la lógica definida en HealthServiceWrapper.
  4. Después de que IHealth/default esté ampliamente disponible y las imágenes de proveedores de Android 8.1 se IHealth/backup, y healthd pueden quedar obsoletos. Para ver más 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, los valores específicos del tablero no se puede definir para los módulos del sistema. En health@2.0, los proveedores pueden anular estos dos valores en healthd_mode_ops->init (si descartas libhealthservice en health@2.0-service.<device> y volver 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 health@2.0-service, charge la recuperación y el vínculo de estado heredado.

Health@2.0.impl implementa IHealth como se describió anteriormente y está diseñado para unir. alrededor de libbatterymonitor y libhealthd.BOARD. Estos los 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 Generalizar además, el código healthd_common también se incluye en health@2.0-impl. La nueva herramienta healthd_common contiene el resto del código común entre health@2.0-service. cargador, healthd y llama a los métodos IHealth en lugar de BatteryMonitor.

Implementa el servicio Health 2.0

Cuando se implementa el servicio health@2.0 para un dispositivo, si la implementación es:

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

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

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

Luego:

  • Si es específica de la placa libhealthd:

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

  • Si hay variables BOARD_PERIODIC_CHORES_INTERVAL_* específicas de la placa:

    • Deben definirse, crear un HealthServiceCommon.cpp específico para el dispositivo (copiado de hardware/interfaces/health/2.0/utils/libhealthservice) y Personalízala en healthd_mode_service_2_0_init.
    • No están definidos. Crea un vínculo a libhealthservice de forma estática.

  • Si se trata de un dispositivo:

    • Debes implementar las APIs de getStorageInfo y getDiskStats, y debes proporcionar el en las funciones get_storage_info y get_disk_stats.
    • No se deberían implementar esas APIs, vincular a libstoragehealthdefault de forma estática.

  • Actualiza los permisos de SELinux necesarios.

  • Para implementar HAL en recuperación, instala una implementación de transferencia al 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 atención médica

Consulta Clientes de salud para la HAL de Health 2.1.

Cambios de SELinux

La nueva HAL de health@2.0 incluye los siguientes cambios de SELinux:

  • Agrega health@2.0-service a file_contexts.
  • Permite que system_server y storaged usen hal_health.
  • Permite que se registre system_server (BatteryService) batteryproperties_service (IBatteryPropertiesRegistrar)
  • Permite que healthd proporcione hal_health.
  • Quita las reglas que permiten que system_server y storaged llamen a De healthd a 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 apliquen algunos cambios de SELinux de los proveedores. necesario. 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 de kernel

Consulta Interfaces del kernel para la HAL de Health 2.1.

Prueba

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

Requisitos de la información sobre la batería

Consulta los Requisitos de la información sobre la batería.