Implementar Health 2.1

En Android 11, todo el código healthd se refactoriza en libhealthloop y libhealth2impl, luego, modificados para implementar health@2.1 HAL. Estas dos bibliotecas están vinculadas estáticamente por health@2.0-impl-2.1, la implementación de transferencia de Health 2.1. Las bibliotecas vinculadas estáticamente Permite que health@2.0-impl-2.1 realice el mismo trabajo que healthd, como ejecutar healthd_mainloop y sondeos. En init, health@2.1-service registra un implementación de la interfaz IHealth en hwservicemanager. Al realizar la actualización con Android 8.x o 9 del proveedor y un framework de Android 11, es posible que la imagen del proveedor no proporcione el servicio health@2.1. Hacia atrás la compatibilidad con las imágenes de proveedores anteriores se implementa cronograma de baja.

Para garantizar la retrocompatibilidad:

  1. healthd registra IHealth en hwservicemanager a pesar de ser un sistema daemon. Se agrega IHealth al manifiesto del sistema, con el nombre de la instancia. “copia de seguridad”.
  2. El framework y storaged se comunican con healthd a través de hwbinder en lugar de binder.
  3. Se cambia el código del framework y storaged para recuperar la instancia “predeterminado” si está disponible, selecciona “copia de seguridad”.
    • El código del cliente C++ usa la lógica definida en libhealthhalutils.
    • El código de cliente de Java usa la lógica definida en HealthServiceWrapper.
  4. Después de que IHealth/default esté ampliamente disponible y las imágenes de proveedores de Android 8.1 se IHealth/backup, y healthd pueden quedar obsoletos. Para ver más más detallados, consulta health@1.0 dejó de estar disponible.

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 compilación entre sistemas y proveedores, los valores específicos del tablero no se puede definir para los módulos del sistema. Estos valores solían anularse en la función obsoleta healthd_board_init.

En health@2.1, los proveedores pueden anular estos dos tareas periódicas: valores de intervalo en el struct healthd_config antes y lo pasa al constructor de la clase de implementación de Health. La salud de implementación de la clase de implementación android::hardware::health::V2_1::implementation::Health

Implementa el servicio Health 2.1

Para obtener información sobre la implementación del servicio Health 2.1, consulta hardware/interfaces/health/2.1/README.md:

Clientes de atención médica

health@2.x tiene los siguientes clientes:

  • cargador. El uso de los códigos libbatterymonitor y healthd_common es envuelto en health@2.0-impl.
  • recuperación. La vinculación con libbatterymonitor está unida health@2.0-impl Todas las llamadas a BatteryMonitor se reemplazan por llamadas a la clase de implementación de Health.

  • BatteryManager. BatteryManager.queryProperty(int id) fue el único cliente de IBatteryPropertiesRegistrar.getProperty. IBatteryPropertiesRegistrar.getProperty fue proporcionada por healthd y leyeron directamente /sys/class/power_supply.

    Como consideración de seguridad, las apps no pueden llamar a la HAL de estado. directamente. En Android 9 y versiones posteriores, Binder el servicio IBatteryPropertiesRegistrar es proporcionado por BatteryService en lugar de healthd. BatteryService delega la llamada a la HAL de estado. para recuperar la información solicitada.

  • BateríaService. En Android 9 y versiones posteriores, BatteryService usa HealthServiceWrapper para determinar si debe usar la Instancia de servicio de salud default de vendor o para usar la copia de seguridad de servicio de salud de healthd. BatteryService luego escucha eventos de salud mediante IHealth.registerCallback.

  • Almacenado. En Android 9 y versiones posteriores, storaged usa libhealthhalutils para determinar si debe usar la Instancia de servicio de salud default de vendor o para usar la copia de seguridad de servicio de salud de healthd. storaged, luego, escucha eventos de salud mediante IHealth.registerCallback y recupera la información de almacenamiento.

Cambios de SELinux

La HAL de health@2.1 incluye los siguientes cambios de SELinux en la plataforma:

  • Se agregó android.hardware.health@2.1-service a file_contexts.

En el caso de los dispositivos con su propia implementación, es posible que se apliquen algunos cambios de SELinux de los proveedores. necesario. 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 de kernel

El daemon healthd y la implementación predeterminada android.hardware.health@2.0-impl-2.1 accede a las siguientes interfaces del kernel para recuperar la información sobre la batería:

  • /sys/class/power_supply/*/capacity_level (agregado en Salud 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 (agregado en Salud 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 (agregado en Salud 2.1)
  • /sys/class/power_supply/*/type
  • /sys/class/power_supply/*/voltage_max
  • /sys/class/power_supply/*/voltage_now

Cualquier implementación de HAL de estado específica del dispositivo que use libbatterymonitor accede a estas interfaces del kernel de forma predeterminada, a menos que se anule en el estado de clase de implementación.

Si faltan estos archivos o no se puede acceder a ellos desde healthd o desde la servicio predeterminado (por ejemplo, el archivo es un symlink a una carpeta específica del proveedor que deniega el acceso debido a una política SELinux mal configurada), es posible que no funcionen correctamente. Por lo tanto, es posible que se apliquen cambios adicionales de SELinux es necesario, incluso aunque se use la implementación predeterminada.

Algunas interfaces de kernel que se usan en Health 2.1, como /sys/class/power_supply/*/capacity_level y /sys/class/power_supply/*/time_to_full_now (puede ser opcional). Sin embargo, para evitar comportamientos incorrectos del framework debido a la falta de interfaces de kernel se recomienda cosechar los mejores CL 1398913 antes de compilar el servicio HAL de Health 2.1.

Prueba

Android 11 incluye nuevos Pruebas de VTS escritas específicamente para la HAL de health@2.1. Si un dispositivo declara Health@2.1 HAL en el manifiesto del dispositivo, esta debe pasar las pruebas de VTS correspondientes. Las pruebas se escriben tanto para la instancia predeterminada (para garantizar que el dispositivo implementa la HAL correctamente) y la instancia de copia de seguridad (para garantizar que healthd siga funcionando correctamente antes de que se quite).

Requisitos de la información sobre la batería

La HAL de Health 2.0 establece un conjunto de requisitos en la interfaz de la HAL, pero la las pruebas de VTS correspondientes son relativamente flexibilizadas respecto de su aplicación. En Android 11, se agregan nuevas pruebas de VTS para aplicar las los siguientes requisitos para los dispositivos que se lanzan con Android 11 y versiones posteriores:

  • Las unidades de corriente instantánea y promedio de la batería deben ser microamperios (μA).
  • El signo de corriente instantánea y promedio de la batería debe ser correcto. Más precisamente, sucederá lo siguiente:
    • Current == 0 cuando el estado de la batería es UNKNOWN
    • actual > 0 cuando el estado de la batería es CHARGING
    • actual <= 0 cuando el estado de la batería es NOT_CHARGING
    • actual < 0 cuando el estado de la batería es DISCHARGING
    • No se aplica de manera forzosa cuando el estado de la batería es FULL
  • El estado de la batería debe ser correcto respecto de si la fuente de alimentación conectado. Más precisamente, sucederá lo siguiente:
    • el estado de la batería debe ser CHARGING, NOT_CHARGING o FULL si y solo si hay una fuente de alimentación conectada.
    • el estado de la batería debe ser DISCHARGING siempre y cuando la fuente de alimentación sea desconectado.

Si usas libbatterymonitor en tu implementación y pasas valores desde las interfaces del kernel, asegúrate de que los nodos sysfs informen valores correctos:

  • Asegúrate de que la corriente de la batería se indique con el signo y las unidades correctos. Esta incluye los siguientes nodos sysfs:
    • /sys/class/power_supply/*/current_avg
    • /sys/class/power_supply/*/current_max
    • /sys/class/power_supply/*/current_now
    • Los valores positivos indican corriente entrante a la batería.
    • Los valores deben estar en microamperios (μA).
  • Asegúrate de que el voltaje de la batería se informe en microvoltios (μV). Esto incluye las Los siguientes nodos sysfs:
    • /sys/class/power_supply/*/voltage_max
    • /sys/class/power_supply/*/voltage_now
    • Ten en cuenta que la implementación predeterminada de HAL divide voltage_now por 1,000. e informa los valores en milivoltios (mV). Consulta @1.0::HealthInfo.

Para obtener más información, consulta Clase de fuente de alimentación de Linux: