Salud de Android

Android 9 incluye android.hardware.health HAL 2.0, una actualización de la versión principal de health@1.0 HAL. Este nuevo HAL tiene las siguientes ventajas:

  • Separación más clara entre el marco y el código del proveedor.
  • healthd el demonio de salud innecesario.
  • Mayores grados de libertad para la personalización del proveedor en los informes de información de salud.
  • Más información sobre el estado del dispositivo que solo la batería.

Android 11 incluye android.hardware.health HAL 2.1, una actualización de versión menor de health@2.0 HAL. Este nuevo HAL tiene las siguientes ventajas:

  • Más fácil de implementar
  • Mejor conformidad con las API HAL 2.0 existentes
  • Mejor separación de agudos en el código de carga fuera de modo
  • Mejor soporte para el marco para indicar el estado de la batería del dispositivo

Android 13 incluye android.hardware.health AIDL HAL, una conversión de health@2.1 HAL. Este nuevo HAL tiene las siguientes ventajas:

  • Eliminar las API relacionadas con el cargador no utilizadas
  • Eliminar StorageAttribute no utilizado y campos relacionados
  • Admite carga de muelle.

Requisitos

Dispositivos con Android 9 y Android 10

Los dispositivos que se inician con Android 9 deben proporcionar la HAL 2.x (y no deben proporcionar la HAL 1.0) o la HAL AIDL. Los dispositivos que no se inicien con Android 9 pero que planeen actualizar la imagen del proveedor a Target Framework Compatibility Matrix versión 3 (lanzado en Android 9) deben eliminar las implementaciones 1.0 HAL existentes y proporcionar 2.x HAL o AIDL HAL.

AOSP incluye varias bibliotecas auxiliares diseñadas para ayudarlo a implementar la HAL 2.0 y la transición de la antigua HAL 1.0.

Dispositivos con Android 11 y Android 12

Los dispositivos que se inician con Android 11 deben proporcionar la HAL 2.1 (y no deben proporcionar la HAL 1.0 o 2.0) o la HAL AIDL. Los dispositivos que no se inicien con Android 11 pero que planeen actualizar la imagen del proveedor a Target Framework Compatibility Matrix versión 5 (lanzado en Android 11) deben eliminar las implementaciones 2.0 HAL existentes y proporcionar 2.1 HAL o AIDL HAL. También se recomienda que los dispositivos que no se inicien con Android 11 y no planeen actualizar la imagen del proveedor proporcionen la HAL 2.1.

AOSP incluye varias bibliotecas auxiliares diseñadas para ayudarlo a implementar la HAL 2.1 y la transición de la antigua HAL 1.0.

Dispositivos con Android 13 y superior

Los dispositivos que se inician con Android 13 deben proporcionar AIDL HAL (y no deben proporcionar HIDL HAL). Los dispositivos que no se inicien con Android 13 pero que planeen actualizar la imagen del proveedor a Target Framework Compatibility Matrix versión 7 (lanzado en Android 13) deben eliminar las implementaciones HIDL HAL existentes y proporcionar AIDL HAL. También se recomienda que los dispositivos que no se inicien con Android 13 y no planeen actualizar la imagen del proveedor proporcionen AIDL HAL.

Los dispositivos no deben proporcionar HIDL 1.0 HAL.

AOSP incluye varias bibliotecas auxiliares diseñadas para ayudarlo a implementar AIDL HAL y la transición de las antiguas HIDL HAL.

Terminología

  • health@1.0 : abreviatura de android.hardware.health@1.0 . Se refiere a la salud HIDL HAL versión 1.0 lanzada en Android 8.0.
  • health@2.0 : abreviatura de android.hardware.health@2.0 . Se refiere a la salud HIDL HAL versión 2.0 lanzada en Android 9.
  • health@2.1 : abreviatura de android.hardware.health@2.1 . Se refiere a la salud HIDL HAL versión 2.1 lanzada en Android 11.
  • salud AIDL HAL : abreviatura de android.hardware.health .
    • La versión 1 se lanza en Android 13.
  • cargador : ejecutable que se ejecuta en modo de carga que muestra la animación de carga del teléfono.
  • recovery : ejecutable que se ejecuta en modo de recuperación que debe recuperar información de la batería.
  • healthd : demonio heredado que se ejecuta en Android que recupera información relacionada con la salud y la proporciona al marco.
  • storaged : demonio que se ejecuta en Android que recupera información de almacenamiento y la proporciona al marco.

Salud en Android 8.x

En Android 8.x, el componente de salud funciona como se detalla en el siguiente diagrama:

Salud en Android 8.x

Figura 1 . Salud en Android 8.x

En este diagrama:

  • El marco utiliza una (1) llamada de enlace y una (1) llamada de hwbinder para comunicarse con el hardware.
  • healthd vincula estáticamente a libhealthd_android , libbatterymonitor y libbatteryservice .
  • health@1.0-impl vincula estáticamente a libhealthd. BOARD .

Cada tablero puede personalizar un libhealthd. BOARD ; se determina en el momento de la compilación a qué se vinculan el cargador, health@1.0-impl y recovery.

Para otros modos:

Modo de carga y recuperación fuera de modo en Android 8.x

Figura 2. Salud en Android 8.x, modo de carga y recuperación fuera de modo

  • cargador se vincula estáticamente a libhealthd. BOARD , libhealthd_charger y libbatterymonitor .
  • recovery vincula estáticamente a libhealthd. BOARD y libbatterymonitor .

Salud en Android 9

En Android 9, el componente de salud funciona como se detalla en el siguiente diagrama: Salud en Android 9

Figura 3 . Salud en Android 9

El marco intenta recuperar el servicio health@2.0 de hwservicemanager . Si falla, llama a health@1.0 (en Android 8.x). La ruta del código heredado se conserva para que la imagen del sistema de Android 9 sea compatible con la imagen del proveedor de Android 8.x. El marco no recupera información de ambas HAL porque solo puede existir una versión de servicio (1.0 o 2.0) en el dispositivo.

Para otros modos:

Carga y recuperación fuera de modo en Android 9

Figura 4. Salud en Android 9, carga fuera de modo y modo de recuperación

Salud en Android 11

En Android 11, el componente de salud funciona como se detalla en el siguiente diagrama:

[system]
    | getService()
    V
[health@2.1-service]
        | getService(stub=true)
        V
[      health@2.0-impl-2.1-<device>.so      ]
        |                                  | (device-dependent linkage)
        V                                  V
+---------Helper libs for impl--------+   [libhealthd.device]
| [libhealthloop (uevent, wakealarm)] |
| [libhealth2impl (IHealth impl)    ] |
| [libbatterymonitor (battery)      ] |
+-------------------------------------+

Si la implementación de salud 2.1 no existe, el sistema recurre a la ruta del código heredado como se describe en las secciones anteriores.

Para otros modos:

[       charger          ]
    | getService()      |  (legacy code path)
    V                   +-------------------------------------------------+
[health@2.1-service]                                                      |
        | getService(stub=true)                                           |
        V                                                                 |
[      health@2.0-impl-2.1-<device>.so      ]                             |
        |                                  | (device-dependent linkage)   |
        V                                  V                              |
+---------Helper libs for impl--------+   [libhealthd.device]             |
| [libhealthloop (uevent, wakealarm)] |                                   |
| [libhealth2impl (IHealth impl)    ] | <---------------------------------+
| [libbatterymonitor (battery)      ] |
+-------------------------------------+
[recovery]
        | getService() w/o hwservicemanager
        V
[      health@2.0-impl-2.1-<device>.so      ]
        |                                  | (device-dependent linkage)
        V                                  V
+---------Helper libs for impl--------+   [libhealthd.device]
| [libhealthloop (uevent, wakealarm)] |
| [libhealth2impl (IHealth impl)    ] |
| [libbatterymonitor (battery)      ] |
+-------------------------------------+

Vea el siguiente diagrama simplificado para diferentes modos:

Salud HAL 2.1 infraestructura

Figura 5. Infraestructura HAL 2.1 de salud

Salud en Android 13

En Android 13, se presenta el AIDL HAL de salud. El componente de salud funciona como se detalla en el siguiente diagrama:

Salud AIDL HAL infraestructura

Figura 6. Infraestructura HAL AIDL Salud

Interfaz HIDL HAL 2.0

El HAL health@2.0 proporciona la misma funcionalidad al marco que el antiguo daemon healthd. También proporciona API que son similares a las que healthd proporcionó anteriormente como un servicio de enlace (es decir , IBatteryPropertiesRegistrar ).

La interfaz principal, IHealth , proporciona las siguientes funciones:

  • registerCallback , para reemplazar IBatteryPropertiesRegistrar.registerListener
  • unregisterCallback , para reemplazar IBatteryPropertiesRegistrar.unregisterListener
  • update , para reemplazar IBatteryPropertiesRegistrar.scheduleUpdate
  • IBatteryPropertiesRegistrar.getProperties se reemplazan por lo siguiente:
    • getChargeCounter
    • getCurrentNow
    • getCurrentAverage
    • getCapacity
    • getEnergyCounter
    • getChargeStatus
    • getHealthInfo

Además, IHealth proporciona las siguientes API nuevas para storaged para recuperar información relacionada con el almacenamiento específico del proveedor:

  • getStorageInfo
  • getDiskStats

Se devuelve una nueva estructura, @2.0::HealthInfo , mediante devoluciones de llamada y getHealthInfo . Esta estructura contiene toda la información de salud del dispositivo disponible a través de health@2.0 HAL, que incluye:

  • Información de carga (AC/USB/inalámbrico, corriente, voltaje, etc.)
  • Información de la batería (presencia, nivel de batería, corriente, voltaje, carga, tecnología, etc.)
  • Información de almacenamiento (información del dispositivo de almacenamiento, estadísticas del disco)

Para obtener información sobre la implementación del servicio de Salud 2.0, consulte Implementación de Salud 2.0 .

Interfaz HIDL HAL 2.1

Health@2.1 HAL admite la carga en modo desactivado y proporciona más información sobre la batería.

La interfaz principal, IHealth , proporciona las siguientes funciones adicionales

  • getHealthConfig : para recuperar la configuración de esta HAL
  • getHealthInfo_2_1 : una actualización de versión menor a getHealthInfo
  • shouldKeepScreenOn : para determinar si la pantalla debe mantenerse encendida en modo cargador

Además, se requiere la implementación de @2.1::IHealth para admitir @2.1::IHealthInfoCallback para sus funciones heredadas registerCallback y unregisterCallback . La nueva interfaz de devolución de llamada devuelve información de salud al cliente mediante su función healthInfoChanged_2_1 en lugar de la función heredada healthInfoChanged .

Se devuelve una nueva estructura, @2.1::HealthInfo , mediante devoluciones de llamada y getHealthInfo_2_1 . Esta estructura contiene información adicional sobre el estado del dispositivo disponible a través de health@2.0 HAL, que incluye:

  • Nivel de capacidad de la batería
  • Tiempo de carga total de la batería ahora (en segundos)
  • Capacidad de diseño de carga completa de la batería (en μAh)

Consulte el siguiente diagrama UML para ver las clases útiles para la implementación HAL de salud:

Salud 2.1 Diagrama HAL UML

Figura 7. Diagrama de salud HAL 2.1 UML

Para obtener información sobre la implementación del servicio de Salud 2.1, consulte Implementación de Salud 2.1 .

Interfaz AIDL HAL versión 1

Cambios en la API

AIDL versión 1 HAL admite API similares a HIDL 2.1 HAL. En comparación con la interfaz HIDL 2.1, se modifica lo siguiente en la API:

  • Las API relacionadas con el cargador introducidas en HIDL HAL 2.1 no se transfieren a AIDL HAL. Debido a que la funcionalidad de cobro fuera de modo solo se encuentra en la partición /vendor , las API en la interfaz de proveedores no son necesarias. Para implementar correctamente la carga en modo desactivado, consulte el cargador a continuación.
  • El tipo StorageAttribute y los campos relacionados se eliminan porque no se usan.
  • chargerDockOnline se agrega a HealthInfo para admitir la carga del muelle.

Implementación

Consulte el siguiente diagrama UML para ver las clases útiles para la implementación HAL de salud:

Salud AIDL HAL UML diagrama

Figura 8. Diagrama de salud AIDL HAL UML

Para obtener información sobre la implementación del servicio AIDL de salud, consulte Implementación de HAL AIDL de salud .

Recuperación

Android 13 admite Binder en recuperación. La instalación del servicio Health AIDL en recuperación le permite ejecutarse en modo de recuperación.

Para obtener información sobre cómo instalar el servicio AIDL de salud para la recuperación, consulte lo siguiente:

Cargador

La funcionalidad de carga fuera de modo se mueve de /system a /vendor . Para los dispositivos que se inician con Android 13, si admiten la carga fuera de modo, el binario del servicio HAL debe admitir el modo de cargador. Para ello, consulte la implementación del cargador .

Propiedades del sistema de carga

El binario del charger ya no puede leer las propiedades ro.charger.* en /vendor . Si su dispositivo tiene configurada alguna de las propiedades del sistema ro.charger.* , consulte las propiedades del sistema para el cargador .