Salud del sistema Android

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

  • Separación más limpia entre el marco y el código del proveedor.
  • Desaproba el demonio healthd innecesario.
  • Mayores grados de libertad para la personalización de proveedores 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 en modo apagado
  • 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
  • Soporte de carga por muelle.

Requisitos

Dispositivos con Android 9 y Android 10

Los dispositivos que se inician con Android 9 deben proporcionar HAL 2.x (y no deben proporcionar HAL 1.0) o HAL AIDL. Los dispositivos que no se inician con Android 9 pero que planean actualizar la imagen del proveedor a la versión 3 de la matriz de compatibilidad de Target Framework (lanzada en Android 9) deben eliminar las implementaciones HAL 1.0 existentes y proporcionar HAL 2.x o HAL AIDL.

AOSP incluye varias bibliotecas auxiliares diseñadas para ayudarle a implementar HAL 2.0 y la transición desde el antiguo HAL 1.0.

Dispositivos con Android 11 y Android 12

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

AOSP incluye varias bibliotecas auxiliares diseñadas para ayudarle a implementar HAL 2.1 y la transición desde el antiguo 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 inician con Android 13 pero que planean actualizar la imagen del proveedor a Target Framework Compatibility Matrix versión 7 (lanzada en Android 13) deben eliminar las implementaciones HIDL HAL existentes y proporcionar AIDL HAL. También se recomienda que los dispositivos que no se inician con Android 13 y no planean 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 ayudarle a implementar AIDL HAL y la transición de las antiguas HIDL HAL.

Terminología

  • salud@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.
  • salud@2.0 : abreviatura de android.hardware.health@2.0 . Se refiere a la salud HIDL HAL versión 2.0 lanzada en Android 9.
  • salud@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 apagado y que muestra la animación de carga del teléfono.
  • recuperación : ejecutable que se ejecuta en modo de recuperación y que debe recuperar información de la batería.
  • healthd : demonio heredado que se ejecuta en Android y que recupera información relacionada con la salud y la proporciona al marco.
  • almacenado : demonio que se ejecuta en Android y 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 carpeta y una (1) llamada de hwbinder para comunicarse con el hardware.
  • healthd se vincula estáticamente a libhealthd_android , libbatterymonitor y libbatteryservice .
  • health@1.0-impl enlaza estáticamente con libhealthd. BOARD .

Cada placa puede personalizar una libhealthd. BOARD ; se determina en el momento de la compilación a qué se vinculan el cargador, la salud@1.0-impl y la recuperación.

Para otros modos:

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

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

  • El cargador se vincula estáticamente a libhealthd. BOARD , libhealthd_charger y libbatterymonitor .
  • La recuperación se 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 salud@1.0 (en Android 8.x). La ruta del código heredado se mantiene para que la imagen del sistema Android 9 sea compatible con la imagen del proveedor de Android 8.x. El marco no recupera información de ambos 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 del modo en Android 9

Figura 4. Salud en Android 9, modo apagado de carga 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 Health 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)      ] |
+-------------------------------------+

Consulte el siguiente diagrama simplificado para diferentes modos:

Infraestructura de salud HAL 2.1

Figura 5. Infraestructura de salud HAL 2.1.

Salud en Android 13

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

Salud AIDL HAL infraestructura

Figura 6. Infraestructura de salud AIDL HAL.

Interfaz HIDL-HAL 2.0

Health@2.0 HAL proporciona la misma funcionalidad al marco que el antiguo demonio healthd. También proporciona API que son similares a las que Healthd proporcionaba anteriormente como servicio de carpeta (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 que storaged recupere información relacionada con el almacenamiento específica 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 sobre el estado del dispositivo disponible a través de health@2.0 HAL, que incluye:

  • Información de carga (CA/USB/inalámbrica, 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 Health 2.0, consulte Implementación de Health 2.0 .

Interfaz HIDL-HAL 2.1

Health@2.1 HAL admite la carga en modo apagado 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 este HAL
  • getHealthInfo_2_1 : una actualización de versión menor para 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 utilizando su función healthInfoChanged_2_1 en lugar de la función healthInfoChanged heredada.

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 de la batería hasta completarse ahora (en segundos)
  • Capacidad de diseño de carga completa de la batería (en μAh)

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

Diagrama UML HAL de salud 2.1

Figura 7. Diagrama UML de Health HAL 2.1.

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

Interfaz AIDL HAL versión 1

Cambios de API

El HAL AIDL versión 1 admite API similares al HAL HIDL 2.1. En comparación con la interfaz HIDL 2.1, lo siguiente cambia en la API:

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

Implementación

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

Diagrama UML de AIDL HAL de salud

Figura 8. Diagrama UML de salud AIDL HAL.

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 carpeta 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 recuperación, consulte lo siguiente:

Cargador

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

Propiedades del sistema de carga

Las propiedades ro.charger.* ya no son legibles por el binario charger en /vendor . Si su dispositivo tiene configuradas alguna de las propiedades del sistema ro.charger.* , consulte las propiedades del sistema para el cargador .