Android 9 incluye HAL 2.0 android.hardware.health, una actualización de versión importante desde HAL health@1.0. Esta nueva HAL tiene las siguientes ventajas:
- Separación más clara entre el framework y el código del proveedor.
- El daemon
healthdinnecesario deja de estar disponible. - 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 HAL 2.1 de android.hardware.health, una actualización de versión menor de HAL de health@2.0. Este nuevo HAL tiene las siguientes ventajas:
- Son más fáciles de implementar.
- Mayor conformidad con las APIs de HAL 2.0 existentes
- Mejor separación de agudos en el código de carga en modo de apagado
- Mejor compatibilidad con el framework para indicar el estado de la batería del dispositivo
Android 13 incluye la HAL de AIDL de android.hardware.health, una conversión de la HAL de health@2.1. Esta nueva HAL tiene las siguientes ventajas:
- Cómo quitar las APIs relacionadas con cargadores que no se usan
- Quita los campos
StorageAttributey relacionados que no se usan - 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 HAL de 2.x (y no la de 1.0) o la HAL de AIDL. Los dispositivos que no se lanzan con Android 9, pero planean actualizar la imagen del proveedor a la versión 3 de la matriz de compatibilidad del framework de destino (lanzada en Android 9), deben quitar las implementaciones de HAL 1.0 existentes y proporcionar la HAL 2.x o la HAL del AIDL.
AOSP incluye varias bibliotecas auxiliares diseñadas para ayudarte a implementar la HAL 2.0 y la transición de la HAL 1.0 anterior.
Dispositivos que ejecutan Android 11 y Android 12
Los dispositivos que se lanzan con Android 11 deben proporcionar la HAL 2.1 (y no la HAL 1.0 o 2.0) o la HAL de AIDL. Los dispositivos que no se lancen con Android 11, pero que planeen actualizar la imagen del proveedor a la versión 5 de la matriz de compatibilidad del framework de destino (lanzada en Android 11), deben quitar las implementaciones existentes de HAL 2.0 y proporcionar el HAL 2.1 o el HAL de AIDL. También se recomienda que los dispositivos que no se inicien con Android 11 y que no planeen actualizar la imagen del proveedor proporcionen la HAL 2.1.
AOSP incluye varias bibliotecas de ayuda diseñadas para ayudarte a implementar el HAL 2.1 y la transición desde el antiguo HAL 1.0.
Dispositivos con Android 13 y versiones posteriores
Los dispositivos que se lancen con Android 13 deben proporcionar la HAL de AIDL (y no deben proporcionar la HAL de HIDL). Los dispositivos que no se lancen con Android 13, pero que planeen actualizar la imagen del proveedor a la versión 7 de la matriz de compatibilidad del framework de destino (lanzada en Android 13), deben quitar las implementaciones existentes de la HAL de HIDL y proporcionar la HAL de AIDL. También se recomienda que los dispositivos que no se lanzan con Android 13 y que no planean actualizar la imagen del proveedor proporcionen 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 la HAL de AIDL y la transición de las HAL de HIDL antiguas.
Terminología
- health@1.0: abreviatura de
android.hardware.health@1.0Se refiere a la versión 1.0 de la HAL del HIDL de estado lanzada en Android 8.0. - health@2.0: Es la abreviatura de
android.hardware.health@2.0. Se refiere a la versión 2.0 de la HAL de HIDL de salud que se lanzó en Android 9. - health@2.1: Es la abreviatura de
android.hardware.health@2.1. Se refiere a la versión 2.1 de la HAL del HIDL de estado lanzada en Android 11. - HAL de AIDL de Health: Es la abreviatura de
android.hardware.health.- La versión 1 se lanzó en Android 13.
- charger: Es un ejecutable que se ejecuta en la carga en modo de apagado y muestra la animación de carga del teléfono.
- recovery: Es un ejecutable que se ejecuta en modo de recuperación y que debe recuperar información de la batería.
- healthd: Es un daemon heredado que se ejecuta en Android y que recupera información relacionada con la salud y la proporciona al framework.
- storaged: Es un daemon que se ejecuta en Android y recupera información de almacenamiento y la proporciona al framework.
Salud en Android 8.x
En Android 8.x, el componente de estado funciona como se detalla en el siguiente diagrama:
Figura 1. Salud en Android 8.x.
En este diagrama, se ilustra lo siguiente:
- El framework usa una (1) llamada a Binder y una (1) llamada a hwbinder para comunicarse con el hardware.
healthdse vincula de forma estática alibhealthd_android,libbatterymonitorylibbatteryservice.- health@1.0-impl se vincula estáticamente a
libhealthd.BOARD.
Cada placa puede personalizar un libhealthd.BOARD diferente. Se determina en el tiempo de compilación a qué cargador, health@1.0-impl y vínculo de recuperación se vincula.
Para otros modos, haz lo siguiente:
Figura 2: Salud en Android 8.x, carga fuera del modo y modo de recuperación.
- charger se vincula de forma estática a
libhealthd.BOARD,libhealthd_chargerylibbatterymonitor. - la recuperación se vincula de forma estática a
libhealthd.BOARDylibbatterymonitor.
Salud en Android 9
En Android 9, el componente de estado funciona como se detalla en el siguiente diagrama:
Figura 3. Salud en Android 9
El framework intenta recuperar el servicio de health@2.0 desde hwservicemanager.
Si falla, llama a health@1.0 (en Android 8.x). La ruta de acceso 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 framework 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, haz lo siguiente:
Figura 4: Estado en Android 9, carga en modo de apagado y modo de recuperación
Salud en Android 11
En Android 11, el componente de estado 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 no existe la implementación de Health 2.1, el sistema recurre a la ruta de acceso de código heredada, como se describe en las secciones anteriores.
Para otros modos, haz lo siguiente:
[ 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 ver los diferentes modos:
Figura 5: Infraestructura de HAL 2.1 de Health
Estado en Android 13
En Android 13, se presenta la HAL del AIDL de Health. El componente de salud funciona como se detalla en el siguiente diagrama:
Figura 6: Infraestructura de HAL de AIDL de Health
Interfaz 2.0 de la HAL de HIDL
El HAL de health@2.0 proporciona la misma funcionalidad al framework que el antiguo daemon de healthd. También proporciona APIs que son similares a las que se proporcionaron anteriormente como servicio de Binder (es decir, IBatteryPropertiesRegistrar).
La interfaz principal, IHealth, proporciona las siguientes funciones:
registerCallback, para reemplazarIBatteryPropertiesRegistrar.registerListenerunregisterCallback, para reemplazar aIBatteryPropertiesRegistrar.unregisterListenerupdate, para reemplazarIBatteryPropertiesRegistrar.scheduleUpdateIBatteryPropertiesRegistrar.getPropertiesse reemplaza por lo siguiente:getChargeCountergetCurrentNowgetCurrentAveragegetCapacitygetEnergyCountergetChargeStatusgetHealthInfo
Además, IHealth proporciona las siguientes APIs nuevas para que storaged recupere información relacionada con el almacenamiento específica del proveedor:
getStorageInfogetDiskStats
Una struct nueva, @2.0::HealthInfo, se muestra a través de devoluciones de llamada y getHealthInfo.
Esta estructura contiene toda la información de estado del dispositivo disponible a través de HAL de health@2.0, lo que incluye lo siguiente:
- Información de carga (CA/USB/inalámbrica, corriente, voltaje, etcétera)
- Información sobre la batería (presencia, nivel de batería, corriente, voltaje, carga, tecnología, etcétera)
- 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 Health 2.0, consulta Cómo implementar Health 2.0.
Interfaz de la HAL de HIDL 2.1
El 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 este HALgetHealthInfo_2_1: Una actualización de versión secundaria agetHealthInfoshouldKeepScreenOn: Para determinar si la pantalla debe permanecer encendida en el modo de cargador
Además, la implementación de @2.1::IHealth es necesaria para admitir @2.1::IHealthInfoCallback para sus funciones registerCallback y unregisterCallback heredadas. La nueva interfaz de devolución de llamada muestra información de estado al cliente con su función healthInfoChanged_2_1 en lugar de la función healthInfoChanged heredada.
Se muestra una nueva estructura, @2.1::HealthInfo, a través de devoluciones de llamada y getHealthInfo_2_1. Esta estructura contiene información adicional del estado del dispositivo disponible a través del HAL de health@2.0, que incluye lo siguiente:
- 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)
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 Health 2.1, consulta Cómo implementar Health 2.1.
Versión 1 de la interfaz de la HAL de AIDL
Cambios en la API
La HAL de la versión 1 del AIDL admite APIs similares a la HAL del HIDL 2.1. En comparación con la interfaz HIDL 2.1, se cambiaron los siguientes elementos en la API:
- Las APIs relacionadas con el cargador que se introdujeron en la HAL de HIDL 2.1 no se portaron a la HAL de AIDL. Debido a que la funcionalidad de carga en modo de apagado solo se encuentra en la partición
/vendor, no se necesitan las APIs de la interfaz del proveedor. Para implementar la carga fuera del modo de suspensión correctamente, consulta cargador a continuación. - Se quitaron el tipo
StorageAttributey los campos relacionados porque no se usan. - Se agregó
chargerDockOnlineaHealthInfopara admitir la carga en la estación.
Implementación
Consulta el siguiente diagrama de UML para ver las clases útiles para la implementación de HAL de salud:
Figura 8: Diagrama UML del HAL de AIDL de Health.
Para obtener información sobre la implementación del servicio de AIDL de salud, consulta Cómo implementar el HAL de AIDL de salud.
Recuperación
Android 13 admite Binder en la recuperación. La instalación del servicio AIDL de Health en la recuperación permite que se ejecute en modo de recuperación.
Para obtener información sobre cómo instalar el servicio de AIDL de estado en el modo de recuperación, consulta lo siguiente:
Cargador
La funcionalidad de carga en modo de apagado se movió de /system a /vendor. En el caso de los dispositivos que se lanzan con Android 13, si admiten la carga en modo apagado, el objeto binario del servicio de HAL debe admitir el modo de cargador. Para ello, consulta cómo implementar el cargador.
Propiedades del sistema de cargador
El objeto binario charger en /vendor ya no puede leer las propiedades ro.charger.*. Si tu dispositivo tiene configurada alguna de las propiedades del sistema ro.charger.*, consulta las propiedades del sistema para el cargador.