Esta página se ha traducido con Cloud Translation API.

Implementando Salud 2.0

Todo el código healthd ha sido refactorizado en salud@2.0-impl y libhealthservice , luego modificado para implementar salud@2.0 HAL. Estas dos bibliotecas están vinculadas estáticamente mediante el servicio health@2.0, lo que le permite realizar el trabajo realizado anteriormente por healthd (es decir, ejecutar healthd_mainloop y realizar sondeos). En inicio, el servicio health@2.0 registra una implementación de la interfaz IHealth para hwservicemanager . Al actualizar dispositivos con una imagen de proveedor de Android 8.x y un marco de trabajo de Android 9, es posible que la imagen de proveedor no proporcione el servicio health@2.0. Esto se aplica mediante el programa de desuso .

Para resolver este problema:

healthd registra IHealth en hwservicemanager (a pesar de ser un demonio del sistema). IHealth se agrega al manifiesto del sistema, con el nombre de instancia "copia de seguridad".
Framework y storaged se comunican con healthd a través de hwbinder en lugar de binder .
El código para el marco y storaged se cambian para recuperar la instancia "predeterminada" si está disponible, luego "copia de seguridad".
- El código del cliente C++ utiliza la lógica definida en libhealthhalutils .
- El código del cliente Java utiliza la lógica definida en HealthServiceWrapper .
Una vez que IHealth/default esté ampliamente disponible y las imágenes de proveedores de Android 8.1 queden obsoletas, IHealth/backup y healthd podrán quedar obsoletas. Para obtener más detalles, consulte Desuso de health@1.0 .

Variables de construcción específicas de la placa para Healthd

BOARD_PERIODIC_CHORES_INTERVAL_* son variables específicas de la placa que se utilizan para crear healthd . Como parte de la división de compilación del sistema/proveedor, no se pueden definir 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 (eliminando la dependencia libhealthservice en health@2.0-service.<device> y volviendo a implementar esta función).

Biblioteca de implementación estática

A diferencia de otras bibliotecas de implementación HAL, la biblioteca de implementación salud@2.0-impl es una biblioteca estática a la que se vinculan salud@2.0-servicio, cargador, recuperación y salud heredada.

health@2.0.impl implementa IHealth como se describió anteriormente y está destinado a abarcar libbatterymonitor y libhealthd. BOARD . Estos usuarios de health@2.0-impl no deben utilizar BatteryMonitor ni las funciones de libhealthd directamente; en su lugar, estas llamadas deben reemplazarse con 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, cargador y healthd y llama a métodos IHealth en lugar de BatteryMonitor.

Implementación del servicio Salud 2.0

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

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

Entonces:

Si es libhealthd:
- Existe, enlace a él.
- No existe, proporcione implementaciones vacías para las funciones healthd_board_init y healthd_board_battery_update .
Si son variables BOARD_PERIODIC_CHORES_INTERVAL_* específicas de la placa:
- Están definidos, cree un HealthServiceCommon.cpp específico del dispositivo (copiado de hardware/interfaces/health/2.0/utils/libhealthservice ) y personalícelo en healthd_mode_service_2_0_init .
- No están definidos, se vinculan estáticamente a libhealthservice .
Si dispositivo:
- Debe implementar las API getStorageInfo y getDiskStats , proporcionar la implementación en las funciones get_storage_info y get_disk_stats .
- No debería implementar esas API, vincúlelas a libstoragehealthdefault estáticamente.
Actualice los permisos necesarios de SELinux.

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

Clientes de salud

Ver Clientes de salud para salud 2.1 HAL .

Cambios en SELinux

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

Agrega salud@2.0-servicio a file_contexts .
Permite que system_server y storaged utilicen hal_health .
Permite que system_server ( BatteryService ) registre batteryproperties_service ( IBatteryPropertiesRegistrar ).
Permite healthd proporcione hal_health .
Elimina las reglas que permiten que system_server / storaged llame a healthd a través de Binder.
Elimina las reglas que permiten healthd registrar batteryproperties_service ( IBatteryPropertiesRegistrar ).

Para dispositivos con su propia implementación, es posible que sean necesarios algunos cambios de proveedor en SELinux. 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 núcleo

Consulte Interfaces del kernel para Health 2.1 HAL .

Pruebas

Android 9 incluye nuevas pruebas VTS escritas específicamente para Health@2.0 HAL. 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 garantizar que el dispositivo implemente HAL correctamente) como para la instancia de respaldo (para garantizar que healthd continúe funcionando correctamente antes de eliminarlo).

Requisitos de información de la batería

Consulte Requisitos de información de la batería .