Se usó la API de Cloud Translation para traducir esta página.

Implementando Health 2.0

Todo healthd código ha sido reprogramado para health@2.0-impl y libhealthservice , a continuación, modificado para implementar HAL health@2.0. Estas dos bibliotecas están vinculados estáticamente por health@2.0-service, lo que le permite hacer el trabajo previamente realizado por healthd (es decir, ejecutar el healthd_mainloop y hacer polling). En init, el health@2.0-service registra una implementación de la interfaz de IHealth a hwservicemanager . Al actualizar dispositivos con una imagen de proveedor de Android 8.xy un marco de trabajo de Android 9, es posible que la imagen de proveedor no proporcione el servicio health@2.0. Esto se hace cumplir por el programa de desaprobación .

Para resolver este problema:

healthd registra IHealth a hwservicemanager (a pesar de ser un demonio de sistema). IHealth se añade al manifiesto del sistema, con el nombre de instancia "copia de seguridad".
Marco y storaged comunican con healthd través hwbinder en vez de binder .
Código de marco y storaged se cambian a buscar la instancia "por defecto" si está disponible, a continuación, "copia de seguridad".
- Código de cliente C ++ utiliza la lógica definida en libhealthhalutils .
- Código de cliente Java utiliza la lógica definida en HealthServiceWrapper .
Después de iHealth / default está ampliamente disponible y las imágenes de Android 8.1 proveedores están en desuso, iHealth / copia de seguridad y healthd puede ser obsoleta. Para más detalles, véase deprecating health@1.0 .

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

BOARD_PERIODIC_CHORES_INTERVAL_* son variables pensión específico utilizado para construir healthd . Como parte del sistema / proveedor de formación dividida, los valores tablero-específicas no pueden ser definidos para los módulos del sistema. En health@2.0, los proveedores pueden anular estos dos valores en healthd_mode_ops->init (dejando caer libhealthservice dependencia en health@2.0-service.<device> y re-aplicación de esta función).

Biblioteca de implementación estática

A diferencia de otras bibliotecas de aplicación HAL, la biblioteca health@2.0-impl aplicación es una biblioteca estática a la que health@2.0-service, cargador, recuperación y enlace legado healthd.

health@2.0.impl implementa IHealth como se describe anteriormente y está destinado a envolver alrededor de libbatterymonitor y libhealthd. BOARD . Estos usuarios de health@2.0-impl no deben utilizar BatteryMonitor o las funciones en libhealthd directamente; En su lugar, estas llamadas deben ser reemplazadas por llamadas a la Health de clase, una implementación de la IHealth interfaz. Para generalizar más, healthd_common código 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, cargador, y healthd y pone en métodos iHealth en lugar de BatteryMonitor.

Implementación del servicio Health 2.0

Al implementar el servicio health@2.0 para un dispositivo, si la implementación predeterminada es:

Suficiente para el dispositivo, utilice android.hardware.health@2.0-service directamente.
No suficiente para el dispositivo, crear el android.hardware.health@2.0-service.(device) Ejecutable e incluyen:
```
#include <health2/service.h>
int main() { return health_service_main(); }
```

Luego:

Si la tarjeta específica libhealthd:
- Existe, enlace a él.
- No existe, para proporcionar implementaciones vacías healthd_board_init y healthd_board_battery_update funciones.
Si la tarjeta específica BOARD_PERIODIC_CHORES_INTERVAL_* variables:
- Se definen, crear un dispositivo específico HealthServiceCommon.cpp (copiado de hardware/interfaces/health/2.0/utils/libhealthservice ) y personalizarlo en healthd_mode_service_2_0_init .
- No están definidos, enlace a libhealthservice estáticamente.
Si dispositivo:
- Debe aplicar getStorageInfo y getDiskStats API, proporcionar a la aplicación en get_storage_info y get_disk_stats funciones.
- No debe poner en práctica esas API, enlazar a libstoragehealthdefault estáticamente.
Actualice los permisos necesarios de SELinux.

Implemente HAL en recuperación instalando una implementación de paso a través en 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 más detalles, consulte el hardware / las interfaces / salud / 2.0 / README.md .

Clientes de salud

Ver clientes de salud para la salud 2.1 HAL .

Cambios de SELinux

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

Health@2.0-service añade a file_contexts .
Permite system_server y storaged al uso hal_health .
Permite system_server ( BatteryService ) para registrar batteryproperties_service ( IBatteryPropertiesRegistrar ).
Permite healthd para proporcionar hal_health .
Elimina las reglas que permiten system_server / storaged poner en healthd a través de aglutinante.
Elimina las reglas que permiten healthd para registrar batteryproperties_service ( IBatteryPropertiesRegistrar ).

Para dispositivos con su propia implementación, pueden ser necesarios algunos cambios de 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

Ver las interfaces del kernel para la salud 2.1 HAL .

Pruebas

Android 9 incluye nuevas pruebas VTS escritos específicamente para la HAL health@2.0. Si un dispositivo declara proporcionar health@2.0 HAL en el manifiesto del dispositivo, debe pasar las pruebas VTS correspondientes. Las pruebas se escriben tanto para la instancia predeterminada (para asegurar que los implementos de dispositivos la HAL correctamente) y la instancia de copia de seguridad (para asegurar que healthd sigue correctamente a la función antes de que se elimina).

Requisitos de información de la batería

Ver requisitos de información de la batería .