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:
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 alibhealthd_android
,libbatterymonitor
ylibbatteryservice
. - 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:
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
ylibbatterymonitor
. - recovery vincula estáticamente a
libhealthd. BOARD
ylibbatterymonitor
.
Salud en Android 9
En Android 9, el componente de salud funciona como se detalla en el siguiente diagrama:
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:
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:
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:
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 reemplazarIBatteryPropertiesRegistrar.registerListener
-
unregisterCallback
, para reemplazarIBatteryPropertiesRegistrar.unregisterListener
-
update
, para reemplazarIBatteryPropertiesRegistrar.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 agetHealthInfo
-
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:
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 aHealthInfo
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:
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 .