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 [email protected] y libhealthservice , luego se modificó para implementar [email protected] HAL. Estas dos bibliotecas están vinculadas estáticamente por el servicio [email protected], lo que le permite realizar el trabajo que anteriormente realizaba healthd (es decir, ejecutar healthd_mainloop y realizar sondeos). En init, el servicio [email protected] 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 [email protected]. 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 [email protected] .

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 [email protected], los proveedores pueden anular estos dos valores en healthd_mode_ops->init ( libhealthservice dependencia de libhealthservice en [email protected].<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 [email protected] es una biblioteca estática a la que se vinculan [email protected], charger, recovery y legacy healthd.

[email protected] implementa IHealth como se describe arriba y está destinado a envolver libbatterymonitor y libhealthd. BOARD . Estos usuarios de [email protected] 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 [email protected]. El nuevo healthd_common contiene el resto del código común entre [email protected], 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 [email protected] para un dispositivo, si la implementación predeterminada es:

Suficiente para el dispositivo, use [email protected] directamente.
No es suficiente para el dispositivo, cree el ejecutable [email protected].(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: "[email protected]<device>",
    recovery_available: true,
    relative_install_path: "hw",
    static_libs: [
        "[email protected]",
        "libhealthd.<device>"
        // Include the following or implement device-specific storage APIs
        "libhealthstoragedefault",
    ],
    srcs: [
        "HealthImpl.cpp",
    ],
    overrides: [
        "[email protected]",
    ],
}

// 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 += [email protected]<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 [email protected] incluye los siguientes cambios de SELinux:

Agrega [email protected] 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 [email protected] HAL. Si un dispositivo declara proporcionar [email protected] 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 .