En Android 11, todo el código de healthd
se refactoriza en libhealthloop
y libhealth2impl
, y, luego, se modifica para implementar la HAL de health@2.1. health@2.0-impl-2.1
, la implementación de transferencia de Health 2.1, vincula estas dos bibliotecas de forma estática. Las bibliotecas vinculadas de forma estática permiten que health@2.0-impl-2.1
realice el mismo trabajo que healthd
, como ejecutar healthd_mainloop
y realizar sondeos. En init, health@2.1-service
registra una implementación de la interfaz IHealth
en hwservicemanager
. Cuando se actualizan dispositivos con una imagen del proveedor de Android 8.x o 9 y un framework de Android 11, es posible que la imagen del proveedor no proporcione el servicio health@2.1. La programación de baja exige la retrocompatibilidad con imágenes de proveedores anteriores.
Para garantizar la retrocompatibilidad, haz lo siguiente:
healthd
registraIHealth
enhwservicemanager
a pesar de ser un daemon del sistema.IHealth
se agrega al manifiesto del sistema con el nombre de instancia "backup".- El framework y
storaged
se comunican conhealthd
a través dehwbinder
en lugar debinder
. - El código del framework y
storaged
se modificaron para recuperar la instancia "default" si está disponible y, luego, "backup".- El código del cliente C++ usa la lógica definida en
libhealthhalutils
. - El código del cliente de Java usa la lógica definida en
HealthServiceWrapper
.
- El código del cliente C++ usa la lógica definida en
- Después de que IHealth/default esté disponible de forma generalizada y se dejen de usar las imágenes de proveedores de Android 8.1, se podrán dejar de usar IHealth/backup y
healthd
.
Variables de compilación específicas de la placa para healthd
BOARD_PERIODIC_CHORES_INTERVAL_*
son variables específicas de la placa que se usan para compilar healthd
. Como parte de la división de la compilación del sistema/proveedor, no se pueden definir valores específicos de la placa para los módulos del sistema. Estos valores se anulaban en la función healthd_board_init
obsoleta.
En health@2.1, los proveedores pueden anular estos dos valores de intervalo de tareas periódicas en la estructura healthd_config
antes de pasarlos al constructor de la clase de implementación de health. La clase de implementación de Health debe heredar de android::hardware::health::V2_1::implementation::Health
.
Implementa el servicio de Health 2.1
Para obtener información sobre la implementación del servicio de Health 2.1, consulta hardware/interfaces/health/2.1/README.md.
Clientes de salud
health@2.x tiene los siguientes clientes:
- cargador El uso del código
libbatterymonitor
yhealthd_common
se incluye enhealth@2.0-impl
. - recuperación La vinculación a
libbatterymonitor
se incluye enhealth@2.0-impl
. Todas las llamadas aBatteryMonitor
se reemplazan por llamadas a la clase de implementaciónHealth
. BatteryManager.
BatteryManager.queryProperty(int id)
era el único cliente deIBatteryPropertiesRegistrar.getProperty
.IBatteryPropertiesRegistrar.getProperty
fue proporcionado porhealthd
y se leyó directamente/sys/class/power_supply
.Como medida de seguridad, las apps no pueden llamar directamente al HAL de salud. En Android 9 y versiones posteriores, el servicio de Binder
IBatteryPropertiesRegistrar
lo proporcionaBatteryService
en lugar dehealthd
.BatteryService
delega la llamada al HAL de salud para recuperar la información solicitada.BatteryService. En Android 9 y versiones posteriores,
BatteryService
usaHealthServiceWrapper
para determinar si se debe usar la instancia del servicio de salud predeterminada devendor
o la instancia del servicio de salud de copia de seguridad dehealthd
. Luego,BatteryService
escucha los eventos de salud a través deIHealth.registerCallback
.Storaged. En Android 9 y versiones posteriores,
storaged
usalibhealthhalutils
para determinar si se debe usar la instancia del servicio de salud predeterminada devendor
o la instancia del servicio de salud de copia de seguridad dehealthd
.storaged
y, luego, escucha los eventos de salud a través deIHealth.registerCallback
y recupera la información de almacenamiento.
Cambios en SELinux
El HAL health@2.1 incluye los siguientes cambios de SELinux en la plataforma:
- Agrega
android.hardware.health@2.1-service
afile_contexts
.
En el caso de los dispositivos con su propia implementación, es posible que sean necesarios algunos cambios de SELinux del proveedor. Ejemplo:
# device/<manufacturer>/<device>/sepolicy/vendor/hal_health_default.te
# Add device specific permissions to hal_health_default domain, especially
# if it links to board-specific libhealthd or implements storage APIs.
Interfaces del kernel
El daemon healthd
y la implementación predeterminada android.hardware.health@2.0-impl-2.1
acceden a las siguientes interfaces del kernel para recuperar información de la batería:
/sys/class/power_supply/*/capacity_level
(se agregó en Health 2.1)/sys/class/power_supply/*/capacity
/sys/class/power_supply/*/charge_counter
/sys/class/power_supply/*/charge_full
/sys/class/power_supply/*/charge_full_design
(se agregó en Health 2.1)/sys/class/power_supply/*/current_avg
/sys/class/power_supply/*/current_max
/sys/class/power_supply/*/current_now
/sys/class/power_supply/*/cycle_count
/sys/class/power_supply/*/health
/sys/class/power_supply/*/online
/sys/class/power_supply/*/present
/sys/class/power_supply/*/status
/sys/class/power_supply/*/technology
/sys/class/power_supply/*/temp
/sys/class/power_supply/*/time_to_full_now
(se agregó en Health 2.1)/sys/class/power_supply/*/type
/sys/class/power_supply/*/voltage_max
/sys/class/power_supply/*/voltage_now
Cualquier implementación del HAL de salud específica del dispositivo que use libbatterymonitor
accede a estas interfaces del kernel de forma predeterminada, a menos que se anule en el constructor de la clase de implementación de salud.
Si faltan estos archivos o no se puede acceder a ellos desde healthd
o desde el servicio predeterminado (por ejemplo, si el archivo es un vínculo simbólico a una carpeta específica del proveedor que deniega el acceso debido a una política de SELinux mal configurada), es posible que no funcionen correctamente. Por lo tanto, es posible que se necesiten cambios adicionales específicos del proveedor en SELinux, incluso si se usa la implementación predeterminada.
Algunas interfaces del kernel que se usan en Health 2.1, como /sys/class/power_supply/*/capacity_level
y /sys/class/power_supply/*/time_to_full_now
, pueden ser opcionales. Sin embargo, para evitar comportamientos incorrectos del framework como resultado de la falta de interfaces del kernel, se recomienda realizar un cherry-pick de CL 1398913 antes de compilar el servicio de la HAL de Health 2.1.
Prueba
Android 11 incluye nuevas pruebas de VTS escritas específicamente para la HAL health@2.1. Si un dispositivo declara el HAL health@2.1 en el manifiesto del dispositivo, debe superar las pruebas de VTS correspondientes.
Las pruebas se escriben tanto para la instancia predeterminada (para garantizar que el dispositivo implemente el HAL correctamente) como para la instancia de copia de seguridad (para garantizar que healthd
siga funcionando correctamente antes de que se quite).
Requisitos de información sobre la batería
El HAL de Health 2.0 establece un conjunto de requisitos en la interfaz de HAL, pero las pruebas de VTS correspondientes son relativamente flexibles en cuanto a su aplicación. En Android 11, se agregaron nuevas pruebas del VTS para aplicar los siguientes requisitos en los dispositivos que se lancen con Android 11 y versiones posteriores:
- Las unidades de la corriente de batería instantánea y promedio deben ser microamperios (μA).
- El signo de la corriente de batería instantánea y promedio debe ser correcto.
Específicamente:
- current == 0 cuando el estado de la batería es
UNKNOWN
- current > 0 cuando el estado de la batería es
CHARGING
- La corriente es menor o igual a 0 cuando el estado de la batería es
NOT_CHARGING
. - La corriente es inferior a 0 cuando el estado de la batería es
DISCHARGING
. - No se aplica cuando el estado de la batería es
FULL
- current == 0 cuando el estado de la batería es
- El estado de la batería debe ser correcto, independientemente de si hay una fuente de alimentación conectada. Específicamente:
- El estado de la batería debe ser
CHARGING
,NOT_CHARGING
oFULL
si y solo si hay una fuente de alimentación conectada. - El estado de la batería debe ser
DISCHARGING
si y solo si se desconecta una fuente de alimentación.
- El estado de la batería debe ser
Si usas libbatterymonitor
en tu implementación y pasas valores desde las interfaces del kernel, asegúrate de que los nodos de sysfs informen los valores correctos:
- Asegúrate de que la corriente de la batería se informe con el signo y las unidades correctos. Esto incluye los siguientes nodos de sysfs:
/sys/class/power_supply/*/current_avg
/sys/class/power_supply/*/current_max
/sys/class/power_supply/*/current_now
- Los valores positivos indican la corriente entrante en la batería.
- Los valores deben estar en microamperios (μA).
- Asegúrate de que el voltaje de la batería se registre en microvoltios (μV). Esto incluye los siguientes nodos de sysfs:
/sys/class/power_supply/*/voltage_max
/sys/class/power_supply/*/voltage_now
- Ten en cuenta que la implementación predeterminada del HAL divide
voltage_now
entre 1,000 y registra los valores en milivoltios (mV). Consulta @1.0::HealthInfo.
Para obtener más información, consulta Clase de fuente de alimentación de Linux.