Google se compromete a impulsar la igualdad racial para las comunidades afrodescendientes. Obtén información al respecto.

Implementación de la salud 2.1

En Android 11, todos healthd código está reprogramado para libhealthloop y libhealth2impl , a continuación, modificado para implementar el HAL health@2.1. Estas dos bibliotecas están vinculados estáticamente por health@2.0-impl-2.1 , la puesta en práctica de paso a través de la salud 2.1. Las bibliotecas enlazadas estáticamente permiten health@2.0-impl-2.1 para hacer el mismo trabajo que healthd , como correr healthd_mainloop y el sondeo. En init, el health@2.1-service registra una implementación de la interfaz de IHealth a hwservicemanager . Al actualizar dispositivos con una imagen de proveedor de Android 8.xo 9 y un marco de trabajo de Android 11, es posible que la imagen de proveedor no proporcione el servicio health@2.1. La compatibilidad hacia atrás con imágenes antiguas de proveedores se hace cumplir por el programa de desaprobación .

Para garantizar la compatibilidad con versiones anteriores:

  1. healthd registra IHealth a hwservicemanager pesar de ser un demonio del sistema. IHealth se añade al manifiesto del sistema, con el nombre de instancia "copia de seguridad".
  2. El marco y storaged comunican con healthd través hwbinder en vez de binder .
  3. El código para el marco y storaged se cambian a buscar la instancia "por defecto" si está disponible, a continuación, "copia de seguridad".
    • Código de cliente C ++ utiliza la lógica definida en libhealthhalutils .
    • Código de cliente Java utiliza la lógica definida en HealthServiceWrapper .
  4. Después de iHealth / default está ampliamente disponible y las imágenes de Android 8.1 proveedores están en desuso, iHealth / copia de seguridad y healthd puede ser obsoleta. Para más detalles, véase deprecating health@1.0 .

Variables de compilación específicas de la placa para healthd

BOARD_PERIODIC_CHORES_INTERVAL_* son variables pensión específico utilizado para construir healthd . Como parte del sistema / proveedor acumulación split, valores tablero-específicas no pueden ser definidos para módulos del sistema. Estos valores se utilizan para ser anulado en la función obsoleta healthd_board_init .

En health@2.1, los proveedores pueden anular estas dos tareas periódicas valores de intervalo en el healthd_config estructura antes de pasar al constructor de clase de implementación de la salud. La clase de implementación de la salud debe heredar de android::hardware::health::V2_1::implementation::Health .

Implementación del servicio Health 2.1

Para obtener información sobre la implementación del servicio de Salud 2.1, consulte el hardware / las interfaces / salud / 2.1 / README.md .

Clientes de salud

health@2.x tiene los siguientes clientes:

  • cargador. El uso de libbatterymonitor y healthd_common código se envuelve en health@2.0-impl .
  • la recuperación. La vinculación con libbatterymonitor se envuelve en health@2.0-impl . Todas las llamadas a BatteryMonitor son reemplazadas por llamadas a la Health clase de implementación.
  • BatteryManager. BatteryManager.queryProperty(int id) era el único cliente de IBatteryPropertiesRegistrar.getProperty . IBatteryPropertiesRegistrar.getProperty fue proporcionado por healthd y directamente leer /sys/class/power_supply .

    Como consideración de seguridad, las aplicaciones no pueden llamar directamente a Health HAL. En Android 9 y superior, el servicio aglutinante IBatteryPropertiesRegistrar es proporcionado por BatteryService en lugar de healthd . BatteryService delegados de la llamada a la HAL de salud para recuperar la información solicitada.

  • BatteryService. En Android 9 y superior, BatteryService utiliza HealthServiceWrapper para determinar si se debe utilizar la instancia de servicio de salud por defecto del vendor o para utilizar la instancia de servicio de salud de respaldo desde healthd . BatteryService entonces escucha los eventos de salud a través de IHealth.registerCallback .

  • Storaged. En Android 9 y superior, storaged usos libhealthhalutils para determinar si se debe utilizar la instancia de servicio de salud por defecto del vendor o para utilizar la instancia de servicio de salud de respaldo desde healthd . storaged continuación, detecta eventos de salud a través de IHealth.registerCallback y recupera la información de almacenamiento.

Cambios de SELinux

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

  • Agrega android.hardware.health@2.1-service a file_contexts .

Para dispositivos con su propia implementación, pueden ser 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 healthd demonio y la implementación predeterminada android.hardware.health@2.0-impl-2.1 acceder a las siguientes interfaces de kernel para recuperar información de la batería:

  • /sys/class/power_supply/*/capacity_level (añadido en la 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 (añadido en la 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 (añadido en la salud 2.1)
  • /sys/class/power_supply/*/type
  • /sys/class/power_supply/*/voltage_max
  • /sys/class/power_supply/*/voltage_now

Cualquier aplicación HAL salud específico del dispositivo que utiliza libbatterymonitor accede a estas interfaces de kernel por defecto, a menos que se reemplaza en el constructor de clase de implementación de la salud.

Si estos archivos no están presentes o son inaccesibles desde healthd o del servicio predeterminado (por ejemplo, el archivo es un enlace simbólico a una carpeta específica del proveedor que niega el acceso debido a la política de SELinux mal configurado), pueden no funcionar correctamente. Por lo tanto, pueden ser necesarios cambios adicionales de SELinux específicos del proveedor aunque se utilice la implementación predeterminada.

Algunas interfaces del núcleo utilizados en salud 2.1, tales como /sys/class/power_supply/*/capacity_level y /sys/class/power_supply/*/time_to_full_now , pueden ser opcionales. Sin embargo, para evitar conductas incorrectas marco resultantes de falta interfaces del núcleo, se recomienda recoger la cereza- CL 1.398.913 antes de construir el servicio de salud HAL 2.1.

Pruebas

Android 11 incluye nuevas pruebas VTS escritos específicamente para la HAL health@2.1. Si un dispositivo declara health@2.1 HAL en el manifiesto del dispositivo, debe pasar las pruebas VTS correspondientes. Las pruebas se escriben tanto para la instancia predeterminada (para asegurar que los implementos de dispositivos la HAL correctamente) y la instancia de copia de seguridad (para asegurar que healthd sigue correctamente a la función antes de que se elimina).

Requisitos de información de la batería

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

  • Las unidades de corriente de batería intatánea y promedio deben ser microamperios (μA).
  • El signo de la corriente de batería instantánea y media debe ser correcto. Específicamente:
    • == actual estado de la batería 0 cuando 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 estado de la batería es DISCHARGING
    • No se aplican cuando el estado de la batería es FULL
  • El estado de la batería debe ser correcto con respecto a si una fuente de alimentación está conectada o no. Específicamente:
    • estado de la batería debe ser uno de CHARGING , NOT_CHARGING o FULL si y sólo si se conecta una fuente de energía;
    • estado de la batería debe ser DISCHARGING si y sólo si se desconecta la fuente de alimentación.

Si utiliza libbatterymonitor en su implementación y pasa a través de los valores de interfaces del núcleo, garantizar los sysfs nodos están reportando valores correctos:

  • Asegúrese de que la corriente de la batería se informe con el signo y las unidades correctos. Esto 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 en la batería.
    • Los valores deben expresarse en microamperios (μA).
  • Asegúrese de que el voltaje de la batería se indique en microvoltios (μV). Esto incluye los siguientes nodos sysfs:
    • /sys/class/power_supply/*/voltage_max
    • /sys/class/power_supply/*/voltage_now
    • Tenga en cuenta que las brechas de implementación HAL predeterminado voltage_now de 1000 y los valores de informes en milivoltios (mV). Ver @ 1.0 :: HealthInfo .

Para más detalles, ver la clase de fuente de alimentación de Linux .