Estado del sistema Android

Android 9 incluye la HAL 2.0 de android.hardware.health. una actualización de versión principal de la HAL de health@1.0. Esta nueva HAL tiene lo siguiente: ventajas:

• Una separación más clara entre el marco de trabajo y el código del proveedor.
• El daemon healthd innecesario deja de estar disponible.
• Mayores grados de libertad para personalizar el proveedor en la información de salud informes.
• Más información sobre el estado del dispositivo que solo la batería.

Android 11 incluye la HAL 2.1 de android.hardware.health, una actualización de versión secundaria de la HAL de health@2.0. Esta nueva HAL tiene lo siguiente: ventajas:

• Son más fáciles de implementar.
• Mejor cumplimiento con las APIs de HAL existentes 2.0
• Mejor separación de Treble en código de carga fuera del modo
• Se mejoró la compatibilidad con el framework para indicar el estado de la batería de la dispositivo

Android 13 incluye la HAL del AIDL android.hardware.health, una conversión de la HAL de health@2.1. Esta nueva HAL tiene lo siguiente: ventajas:

• Cómo quitar las APIs relacionadas con cargadores que no se usan
• Quita los StorageAttribute sin usar y los campos relacionados.
• Admite la carga de la estación de carga.

Requisitos

Dispositivos con Android 9 y Android 10

Los dispositivos que se lanzan con Android 9 deben proporcionar la versión 2.x HAL (y no debe proporcionar la HAL de 1.0) ni la HAL del AIDL. No se lanzan los dispositivos con Android 9, pero planean actualizar la imagen del proveedor a la versión 3 de la matriz de compatibilidad del framework objetivo (lanzada en Android 9) debe quitar las implementaciones existentes de HAL 1.0 y Proporcionar la HAL 2.x o la HAL del AIDL

AOSP incluye varias bibliotecas auxiliares diseñadas para ayudarte a implementar la versión 2.0 HAL y la transición desde la HAL 1.0 anterior.

Dispositivos que ejecutan Android 11 y Android 12

Los dispositivos que se lanzan con Android 11 deben proporcionar la versión 2.1 HAL (y no debe proporcionar la HAL de 1.0 o 2.0) ni la HAL del AIDL. Dispositivos que no lanzar con Android 11, pero planeamos actualizar imagen del proveedor a la versión 5 de la matriz de compatibilidad del framework de destino (lanzada en Android 11) debe quitar la HAL 2.0 existente. y proporcionan la HAL 2.1 o la HAL del AIDL. No se lanzan los dispositivos con Android 11 y no planean actualizar el proveedor para proporcionar la HAL de 2.1.

AOSP incluye varias bibliotecas auxiliares diseñadas para ayudarte a implementar la versión 2.1 HAL y la transición desde la HAL 1.0 anterior.

Dispositivos con Android 13 y versiones posteriores

Los dispositivos que se lanzan con Android 13 deben proporcionar el AIDL HAL (y no debe proporcionar la HAL de HIDL). Dispositivos que no se lanzan con Android 13, pero se planea actualizar la imagen del proveedor a Target La matriz de compatibilidad con frameworks versión 7 (lanzada en Android 13) debe quitar las implementaciones de HAL de HIDL existentes y proporciona la HAL del AIDL. Los dispositivos que no se lanzan con Android 13 y no planean actualizar la imagen del proveedor también se se recomienda proporcionar la HAL del AIDL.

Los dispositivos no deben proporcionar la HAL de HIDL 1.0.

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

Terminología

• health@1.0: abreviatura de android.hardware.health@1.0 Se refiere a versión 1.0 de la HAL del HIDL de salud lanzada en Android 8.0.
• health@2.0: abreviatura de android.hardware.health@2.0 Se refiere a versión 2.0 de la HAL del HIDL de estado lanzada en Android 9.
• health@2.1: abreviatura de android.hardware.health@2.1 Se refiere a versión 2.1 de la HAL del HIDL de salud lanzada en Android 11.
• HAL del AIDL de estado: Es la abreviatura de android.hardware.health.
  • Se lanzó la versión 1 en Android 13.
• charger: Es ejecutable que se ejecuta en la carga fuera de modo y muestra la animación de carga del teléfono.
• recuperación: es ejecutable en ejecución en modo de recuperación que debe recuperar la batería. información.
• healthd: daemon heredado que se ejecuta en Android y que recupera datos de estado información y la proporciona al framework.
• storaged: daemon que se ejecuta en Android y que recupera información de almacenamiento y la proporciona al framework.

Salud en Android 8.x

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

Figura 1. Salud en Android 8.x.

En este diagrama, se muestra lo siguiente:

• El framework usa una (1) llamada a Binder y una (1) llamada a hwbinder para se comuniquen con el hardware.
• healthd se vincula estáticamente a libhealthd_android, libbatterymonitor y libbatteryservice
• health@1.0-impl se vincula estáticamente a libhealthd.BOARD

En cada placa, se puede personalizar un libhealthd.BOARD diferente. se determina en el momento de la compilación qué cargador, health@1.0-impl y vínculo de recuperación a los que tiene acceso una cuenta.

Para otros modos:

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

• cargador se vincula estáticamente a libhealthd.BOARD, libhealthd_charger y libbatterymonitor.
• la recuperación se vincula de forma estática a libhealthd.BOARD y libbatterymonitor

Salud en Android 9

En Android 9, el componente de salud funciona de la manera en el siguiente diagrama:

Figura 3. Salud en Android 9.

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

Para otros modos:

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

Salud en Android 11

En Android 11, el componente de salud funciona de la manera 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 estado 2.1 no existe, el sistema recurre al de la ruta de código heredada, 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)      ] |
+-------------------------------------+

Consulta el siguiente diagrama simplificado para diferentes modos:

Figura 5: Infraestructura HAL 2.1 de estado.

Salud en Android 13

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

Figura 6: Infraestructura de la HAL del AIDL en buen estado

Interfaz 2.0 de la HAL de HIDL

La HAL de health@2.0 brinda al framework la misma funcionalidad que la anterior un daemon en buen estado. También proporciona APIs que son similares a aquellas proporcionado anteriormente como servicio de Binder (es decir, IBatteryPropertiesRegistrar).

La interfaz principal, IHealth proporciona las siguientes funciones:

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

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

• getStorageInfo
• getDiskStats

Una struct nueva, @2.0::HealthInfo, se muestra a través de devoluciones de llamada y getHealthInfo. Esta struct contiene toda la información sobre el estado del dispositivo disponible mediante health@2.0 HAL, incluido lo siguiente:

• Información de carga (AC/USB/inalámbricos, corriente, voltaje, etc.)
• La información de la batería (presencia, nivel de la 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, consulta Implementación de Health 2.0.

Interfaz 2.1 de la HAL de HIDL

La HAL de health@2.1 admite la carga fuera del modo 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 versión secundaria que se actualiza a getHealthInfo
• shouldKeepScreenOn: Para determinar si la pantalla debe mantenerse encendida en modo de cargador

Además, la implementación de @2.1::IHealth es necesaria para admitir @2.1::IHealthInfoCallback para su registerCallback heredada y unregisterCallback. La nueva interfaz de devolución de llamada muestra el estado información al cliente mediante la función healthInfoChanged_2_1, en lugar de la función healthInfoChanged heredada.

Un struct nuevo, @2.1::HealthInfo, se muestra a través de devoluciones de llamada y getHealthInfo_2_1 Esta struct contiene información adicional sobre el estado del dispositivo disponible a través de la HAL de health@2.0, que incluye lo siguiente:

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

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

Figura 7: Diagrama de UML de la HAL de Health 2.1

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

Versión 1 de la interfaz de la HAL del AIDL

Cambios en la API

La HAL de la versión 1 del AIDL admite APIs similares a la HAL del HIDL 2.1. Comparado con la interfaz HIDL 2.1, los siguientes cambios se modificaron en la API:

• Las APIs relacionadas con el cargador que se introducen en la HAL de HIDL 2.1 no se transfieren al AIDL HAL. Debido a que la funcionalidad de la carga fuera del modo está disponible solo en la /vendor, las APIs en la interfaz de proveedor no son necesarias. Para implementar la carga fuera del modo correctamente, consulta cargador a continuación.
• Se quitan el tipo StorageAttribute y los campos relacionados porque son sin usar.
• Se agregó chargerDockOnline a HealthInfo para admitir la carga de la estación de carga.

Implementación

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

Figura 8: Diagrama de UML de la HAL del AIDL de Health

Para obtener información sobre la implementación del servicio de AIDL de salud, consulta Cómo implementar la HAL del AIDL de Health

Recuperación

Android 13 admite Binder en la recuperación. Instalación del El servicio de AIDL de Health a la recuperación permite que se ejecute en modo de recuperación.

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

• Cómo usar el servicio de HAL del AIDL de estado de ejemplo
• Cambios en el sistema de compilación

Cargador

La funcionalidad de la carga fuera del modo se trasladó de /system a /vendor. Para de dispositivos que se lancen con Android 13, si son compatibles fuera del modo de carga, el objeto binario del servicio HAL debe admitir el modo de cargador. Para ello, sigue estos pasos: consultar implementar cargador.

Propiedades del sistema de cargador

El objeto binario charger ya no puede leer las propiedades ro.charger.* en /vendor Si tu dispositivo tiene establecida alguna de las propiedades del sistema de ro.charger.*, haz lo siguiente: consultar propiedades del sistema para el cargador