A partir del 27 de marzo de 2025, te recomendamos que uses android-latest-release en lugar de aosp-main para compilar y contribuir a AOSP. Para obtener más información, consulta Cambios en AOSP.

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

Implementando Salud 2.0

Todo el código healthd se refactorizó en health@2.0-impl y libhealthservice , luego se modificó para implementar health@2.0 HAL. Estas dos bibliotecas están vinculadas estáticamente por el servicio health@2.0, lo que le permite realizar el trabajo que anteriormente realizaba healthd (es decir, ejecutar healthd_mainloop y realizar sondeos). En init, 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 del proveedor no proporcione el servicio health@2.0. Esto se aplica mediante el programa de desaprobación .

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 "backup".
Framework y storaged se comunican con healthd a través de hwbinder en lugar de binder .
El código para el marco y el storaged se cambian para obtener la instancia "predeterminada" si está disponible, luego "copia de seguridad".
- El código de cliente de C++ usa la lógica definida en libhealthhalutils .
- El código de cliente de Java utiliza la lógica definida en HealthServiceWrapper .
Después de que IHealth/default esté ampliamente disponible y las imágenes del proveedor de Android 8.1 estén en desuso, IHealth/backup y healthd pueden quedar en desuso. Para obtener más detalles, consulte Deprecating health@1.0 .

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

BOARD_PERIODIC_CHORES_INTERVAL_* son variables específicas de la placa que se utilizan para generar healthd . Como parte de la división de compilación del sistema/proveedor, los valores específicos de la placa no se pueden definir para los módulos del sistema. En health@2.0, los proveedores pueden anular estos dos valores en healthd_mode_ops->init ( libhealthservice dependencia de 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 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, charger, recovery y legacy healthd.

health@2.0.impl implementa IHealth como se describe arriba y está destinado a envolver libbatterymonitor y libhealthd. BOARD . Estos usuarios de health@2.0-impl no deben usar BatteryMonitor o las funciones en 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, charger y healthd y llama a los 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(); }
```

Después:

Si libhealthd:
- Existe, enlace a él.
- No existe, proporcione 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:
- 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, vinculan a libhealthservice de forma estática.
Si dispositivo:
- Debe implementar las API getStorageInfo y getDiskStats , proporcione la implementación en las funciones get_storage_info y get_disk_stats .
- No debe implementar esas API, enlace a libstoragehealthdefault estáticamente.
Actualice los permisos necesarios de SELinux.

Implemente HAL en la recuperación mediante la instalación de una implementación de acceso directo 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, consulte hardware/interfaces/health/2.0/README.md .

Clientes de salud

Consulte Clientes de salud para la salud 2.1 HAL .

Cambios de SELinux

La nueva HAL 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 system_server ( BatteryService ) registre batteryproperties_service ( IBatteryPropertiesRegistrar ).
Permite que 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 a healthd 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 núcleo

Consulte Interfaces del núcleo para la salud 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 que se elimine).

Requisitos de información de la batería

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