Sensores Multi-HAL

Sensors Multi-HAL es un framework que permite que los HAL de sensores se ejecuten junto con otros HAL de sensores. La multi-HAL de sensores carga dinámicamente las subHAL de sensores se almacenan como bibliotecas dinámicas en la partición del proveedor y les proporciona una devolución de llamada. que puede controlar la publicación de eventos y la adquisición y liberación del bloqueo de activación. Un sub-HAL de sensores es un HAL de sensores que se compila en un objeto compartido en la partición del proveedor y que usa el framework de multi-HAL. Estas subHAL no dependen unos de otros o del código multi-HAL que contiene la función principal para el proceso.

Los sensores Multi-HAL 2.1, disponibles en dispositivos con Android 11 o versiones posteriores, son una iteración de los sensores Multi-HAL 2.0 que admite la carga de sub-HAL que pueden exponer el tipo de sensor de ángulo de bisagra. Para admitir este tipo de sensor, los subHAL deben usar las APIs de subHAL definidos en las 2.1 Encabezado SubHal.

En el caso de los dispositivos que ejecutan Android 13 o versiones posteriores que usan la HAL del AIDL de sensores, puedes usar la capa de compensación multi-HAL para permitir la capacidad multi-HAL. Para obtener detalles sobre la implementación, ver Cómo usar la HAL de varios sensores con la HAL del AIDL de sensores

Diferencia entre sensores Multi-HAL 2 y sensores HAL 2

Sensores Multi-HAL 2, disponibles en dispositivos con Android 10 o más, presenta varias abstracciones además de la HAL de sensores 2 para facilitar para interactuar con las APIs de HAL. Sensors Multi-HAL 2 presenta la clase HalProxy para controlar la implementación de la interfaz de Sensors HAL 2 y la interfaz V2_1/SubHal (o V2_0/SubHal) para permitir que HalProxy interactúe con sub-HAL.

La interfaz ISensorsSubHal difiere de la interfaz 2.1/ISensors.hal (o 2.0/ISensors.hal) de las siguientes maneras:

  • El método de inicialización pasa una clase IHalProxyCallback en lugar de dos FMQ y ISensorsCallback.
  • Los sub-HAL deben implementar una función de depuración para proporcionar información de depuración en los informes de errores.
  • Las subHAL deben implementar una función de nombre para que la subHAL cargada pueda de las HALs secundarias.

La principal diferencia entre los sensores Multi-HAL 2 y los sensores HAL 2 está en la inicializan funciones. En lugar de proporcionar FMQ, IHalProxyCallback proporciona dos métodos: uno para publicar eventos de sensores y un método para crear bloqueos de activación. Bajo el capó, los sensores Multi-HAL administra todas las interacciones con las FMQ para garantizar la entrega oportuna de sensores de todos los subHAL. Se recomienda que los sub-HAL usen el método createScopedWakelock para delegar la carga de establecer un tiempo de espera para los bloqueos de activación al multi-HAL de sensores y centralizar el uso de bloqueos de activación en un bloqueo de activación común para todo el multi-HAL de sensores, lo que minimiza las llamadas de bloqueo y desbloqueo.

Los sensores Multi-HAL 2 también tienen algunas funciones de seguridad integradas. Controla situaciones en las que el FMQ del sensor está lleno o cuando se reinicia el framework de sensores de Android y se debe restablecer el estado del sensor. Además, cuando los eventos se publican en la clase HalProxy, pero el framework del sensor no puede aceptarlos de inmediato, el multi-HAL de sensores puede mover los eventos a un subproceso en segundo plano para permitir que el trabajo continúe en todos los sub-HAL mientras se esperan que se publiquen los eventos.

Implementación del código fuente y la referencia

Todo el código de HAL de sensores está disponible en hardware/interfaces/sensors/common/default/2.X/multihal/ A continuación, se incluyen algunas indicaciones para algunos recursos.

  • HalProxy.h: La multi-HAL de sensores crea instancias del objeto HalProxy y controla las el paso de datos de las subHAL al marco de trabajo del sensor.
  • HalProxy.cpp: La implementación de HalProxy contiene toda la lógica necesaria para comunicación multiplex entre subHAL y marco de trabajo del sensor.

  • SubHal.h: La interfaz ISensorsSubHal define la interfaz que deben seguir los sub-HAL para ser compatibles con HalProxy. El sub-HAL implementa el método de inicialización para que el objeto HalProxyCallback se pueda usar para postEvents y createScopedWakelock.

    Para las implementaciones de Multi-HAL 2.0, usa la versión 2.0 de SubHal.h.

  • hardware/interfaces/sensors/common/default/2.X/multihal/tests/: Estas pruebas de unidades verifican la implementación de HalProxy.

  • hardware/interfaces/sensors/common/default/2.X/multihal/tests/fake_subhal/: En este ejemplo de implementación de subHAL, se usan sensores falsos para generar de datos no estructurados. Es útil para probar cómo interactúan varios sub-HAL en un dispositivo.

Implementación

En esta sección, se describe cómo implementar sensores Multi-HAL en las siguientes secciones: situaciones:

Cómo usar la HAL de sensores múltiples con la HAL de sensores AIDL

Para permitir la función de varios HAL con la HAL de AIDL de sensores, importa el módulo de la capa de compensación de varios HAL de AIDL, que se encuentra en hardware/interfaces/sensors/aidl/default/multihal/. El módulo controla la conversión entre la definición de la HAL de los sensores HIDL y AIDL y define un wrapper alrededor de la interfaz de varias HAL que se describe en Cómo implementar sensores Multi-HAL 2.1 La HAL múltiple del AIDL la capa de corrección de compatibilidad es compatible con dispositivos que implementan Sensores Multi-HAL 2.1.

La capa de corrección de compatibilidad de varios HAL del AIDL te permite exponer el rastreador de cabeza y tipos de sensores IMU de eje limitado en la HAL del AIDL de sensores. Para usar estos sensores, haz lo siguiente: definidos por la interfaz de la HAL del AIDL, establece el campo type en Estructura SensorInfo en la implementación de getSensorsList_2_1() Esto es seguro porque los campos de tipo de sensor con respaldo de número entero de los HAL de sensores AIDL y HIDL no se superponen.

Cómo implementar sensores Multi-HAL 2.1

Para implementar sensores Multi-HAL 2.1 en un dispositivo nuevo, sigue estos pasos:

  1. Implementa la interfaz ISensorsSubHal como se describe en SubHal.h
  2. Implementa el sensorsHalGetSubHal_2_1 en SubHal.h.

  3. Agrega un objetivo cc_library_shared para compilar la subHAL recién implementada. Cuando agregues el objetivo, haz lo siguiente:

    1. Asegúrate de que el destino se envíe a algún lugar de la partición del proveedor del dispositivo.
    2. En el archivo de configuración ubicado en /vendor/etc/sensors/hals.conf, agrega la ruta de acceso a la biblioteca en una línea nueva. Si es necesario, crea el archivo hals.conf.

    Si deseas ver una entrada Android.bp de ejemplo para compilar una biblioteca de subHAL, consulta la siguiente información: hardware/interfaces/sensors/common/default/2.X/multihal/tests/Android.bp

  4. Quita todas las entradas de android.hardware.sensors del manifest.xml que contiene la lista de HALs compatibles con el dispositivo.

  5. Quitar todos los archivos de servicio y service.rc de android.hardware.sensors de el archivo device.mk y agrega android.hardware.sensors@2.1-service.multihal y android.hardware.sensors@2.1-service.multihal.rc para PRODUCT_PACKAGES

Durante el inicio, se inicia HalProxy, se busca el sub-HAL implementado recientemente y se lo inicializa llamando a sensorsHalGetSubHal_2_1.

Conversión de Multi-HAL 2.0 de sensores a Multi-HAL 2.1

Para realizar la portabilidad de Multi-HAL 2.0 a Multi-HAL 2.1, implementa la interfaz de SubHal y vuelve a compilar tu sub-HAL.

Estas son las diferencias entre las interfaces SubHal 2.0 y 2.1:

  • IHalProxyCallback usa los tipos creados en la versión 2.1 de la especificación ISensors.hal.
  • La función initialize() pasa un nuevo IHalProxyCallback en lugar de la de la interfaz SubHal 2.0.
  • Las subHAL deben implementar getSensorsList_2_1 y injectSensorData_2_1 en lugar de getSensorsList y injectSensorData, ya que estos métodos usan los tipos nuevos agregados en la versión 2.1 de la especificación ISensors.hal
  • Las subHAL deben exponer sensorsHalGetSubHal_2_1 en lugar de sensorsHalGetSubHal para que la Multi-HAL las trate como versión 2.1 subHAL.

Portación de la HAL de sensores 2.0

Cuando actualices a Sensors Multi-HAL 2.0 desde la HAL de sensores 2.0, asegúrate de que la implementación de HAL cumpla con los siguientes requisitos.

Cómo inicializar la HAL

La HAL de sensores 2.0 tiene una función de inicialización que permite que el servicio de sensores pase FMQ y una devolución de llamada de sensor dinámica. En Sensors Multi-HAL 2.0, el La función initialize() pasa una sola devolución de llamada que se debe usar para publicar. de sensores, obtener bloqueos de activación y notificar desconexiones.

Publica eventos de sensores en la implementación de Multi-HAL

En lugar de publicar eventos de sensores a través de FMQ, la subHAL debe escribir eventos a la IHalProxyCallback cuando hay eventos de sensores disponibles.

Eventos WAKE_UP

En la HAL de sensores 2.0, la HAL puede administrar el bloqueo de activación para su implementación. En los sensores Multi-HAL 2.0, los sub-HAL permiten que la implementación de Multi-HAL administre los bloqueos de activación y puede solicitar que se adquiera un bloqueo de activación invocando a createScopedWakelock. Se debe adquirir un bloqueo de activación con alcance bloqueado y pasarlo a postEvents cuando se publiquen eventos de activación en la implementación de Multi-HAL.

Sensores dinámicos

Sensors Multi-HAL 2.0 requiere que se llame a onDynamicSensorsConnected y onDynamicSensorsDisconnected en IHalProxyCallback cada vez que cambien las conexiones de sensores dinámicos. Estas devoluciones de llamada son disponible como parte del puntero IHalProxyCallback que se proporciona con la función initialize().

Puerto del HAL de sensores 1.0

Cuando actualizas a la HAL de sensores 2.0 desde la HAL de sensores 1.0, asegúrate de que la HAL que tu implementación cumpla con los siguientes requisitos.

Inicializa el sistema HAL

La función initialize() debe admitirse para establecer la devolución de llamada entre el sub-HAL y la implementación de Multi-HAL.

Expone los sensores disponibles

En Sensors Multi-HAL 2.0, la función getSensorsList() debe mostrar el mismo valor durante el inicio de un solo dispositivo, incluso en los reinicios de HAL de los sensores. Esto permite que el framework intente restablecer las conexiones de los sensores si se reinicia el servidor del sistema. El valor que muestra getSensorsList() puede cambiar después de que se activa el dispositivo. realiza un reinicio.

Publicación de eventos del sensor en la implementación de Multi-HAL

En la HAL de sensores 2.0, en lugar de esperar a que se llame a poll(), el sub-HAL debe escribir de forma proactiva los eventos del sensor en IHalProxyCallback cada vez que estén disponibles.

Eventos WAKE_UP

En el HAL de sensores 1.0, el HAL puede administrar el bloqueo de activación para su implementación. En Multi-HAL 2.0, las subHAL permiten que la implementación de varias HAL administrar bloqueos de activación y puede solicitar que se adquiera uno invocando createScopedWakelock Se debe adquirir un bloqueo de activación con alcance bloqueado y pasarlo a postEvents cuando se publiquen eventos de activación en la implementación de Multi-HAL.

Sensores dinámicos

En la HAL de sensores 1.0, los sensores dinámicos se devuelven a través de la función poll(). Multi-HAL de sensores 2.0 requiere que onDynamicSensorsConnected y onDynamicSensorsDisconnected in IHalProxyCallback se llama cada vez que cambian las conexiones dinámicas de los sensores. Estas devoluciones de llamada son disponible como parte del puntero IHalProxyCallback que se proporciona con la función initialize().

Puerto de los sensores Multi-HAL 1.0

Para portar una implementación existente desde Sensors Multi-HAL 1.0, sigue estos pasos.

  1. Asegúrate de que la configuración de la HAL de los sensores esté ubicada en /vendor/etc/sensors/hals.conf Esto podría implicar mover el archivo ubicado a las /system/etc/sensors/hals.conf.
  2. Quita todas las referencias a hardware/hardware.h y hardware/sensors.h, ya que no son compatibles con HAL 2.0.
  3. Migra los sub-HAL como se describe en Migración desde el HAL de sensores 1.0.
  4. Para establecer Sensors Multi-HAL 2.0 como el HAL designado, sigue los pasos 3 y 4 de la sección Implementación de Sensors Multi-HAL 2.0.

Validación

Ejecuta VTS

Cuando integres uno o más subHAL con Sensores Multi-Hal 2.1, usa el Conjunto de pruebas de proveedores (VTS) para asegurarte de que tu sub-HAL cumplan con todos los requisitos establecidos por la interfaz de la HAL de sensores.

Para ejecutar solo las pruebas de VTS de los sensores cuando el VTS está configurado en una máquina anfitrión, ejecuta los siguientes comandos:

vts-tradefed run commandAndExit vts \
    --skip-all-system-status-check \
    --primary-abi-only \
    --skip-preconditions \
    --module VtsHalSensorsV2_0Target && \
  vts-tradefed run commandAndExit vts \
    --skip-all-system-status-check \
    --primary-abi-only \
    --skip-preconditions \
    --module VtsHalSensorsV2_1Target

Si estás ejecutando la capa de corrección de compatibilidad de varias HAL del AIDL, ejecuta VtsAidlHalSensorsTargetTest.

vts-tradefed run commandAndExit vts \
    --skip-all-system-status-check \
    --primary-abi-only \
    --skip-preconditions \
    --module VtsAidlHalSensorsTargetTest

Cómo ejecutar pruebas de unidades

Las pruebas de unidades en HalProxy_test.cpp prueban HalProxy con sub-HAL falsos que se crean instancias en la prueba de unidades y no se cargan de forma dinámica. Al crear un nuevas subHAL, estas pruebas deben servir como guía para agregar pruebas de unidades que y verifica que se haya implementado correctamente la nueva subHAL.

Para ejecutar las pruebas, ejecuta los siguientes comandos:

cd $ANDROID_BUILD_TOP/hardware/interfaces/sensors/common/default/2.X/multihal/tests
atest

Prueba con los sub-HAL falsos

Los sub-HAL falsos son implementaciones simuladas de la interfaz ISensorsSubHal. Las subHAL exponen diferentes listas de sensores. Cuando se activan los sensores, publican de forma periódica eventos de sensores generados automáticamente en HalProxy según los intervalos especificados en una solicitud de sensor determinada.

Las subHAL falsas se pueden usar para probar cómo funciona el código completo de varias HAL con otras subHAL cargados en el sistema y para destacar varios aspectos del Código HAL de sensores múltiples.

Hay dos subHAL falsos disponibles en hardware/interfaces/sensors/common/default/2.X/multihal/tests/fake_subhal/

Para compilar y enviar las subHAL falsas a un dispositivo, sigue estos pasos:

  1. Ejecuta los siguientes comandos para compilar y enviar los tres sub-HAL falsos al dispositivo:

    $ANDROID_BUILD_TOP/hardware/interfaces/sensors/common/default/2.X/multihal/tests/
mma
adb push \
  $ANDROID_BUILD_TOP/out/target/product/<device>/symbols/vendor/lib64/android.hardware.sensors@2.X-fakesubhal-config1.so \
  /vendor/lib64/android.hardware.sensors@2.X-fakesubhal-config1.so
adb push \
  $ANDROID_BUILD_TOP/out/target/product/<device>/symbols/vendor/lib64/android.hardware.sensors@2.X-fakesubhal-config2.so \
  /vendor/lib64/android.hardware.sensors@2.X-fakesubhal-config2.so
adb push \
  $ANDROID_BUILD_TOP/out/target/product/<device>/symbols/vendor/lib64/android.hardware.sensors@2.X-fakesubhal-config3.so \
  /vendor/lib64/android.hardware.sensors@2.X-fakesubhal-config3.so

  2. Actualiza la configuración de HAL de los sensores en /vendor/etc/sensors/hals.conf con las rutas de acceso de los sub-HAL falsos.

    /vendor/lib64/android.hardware.sensors@2.X-fakesubhal-config1.so
/vendor/lib64/android.hardware.sensors@2.X-fakesubhal-config2.so
/vendor/lib64/android.hardware.sensors@2.X-fakesubhal-config3.so

  3. Reinicia HalProxy y carga los nuevos sub-HAL que se enumeran en la configuración.

    adb shell stop
adb shell start

Depuración

Los desarrolladores pueden depurar el framework con el comando lshal. Para solicitar la resultado de depuración de la HAL de sensores, ejecuta el siguiente comando:

adb root
adb shell lshal debug android.hardware.sensors@2.1::ISensors/default

Luego, la información sobre el estado actual de HalProxy y sus sub-HAL se muestra en la terminal. A continuación, se muestra un ejemplo del resultado del comando para la HalProxy y subHAL falsas.

Internal values:
  Threads are running: true
  Wakelock timeout start time: 200 ms ago
  Wakelock timeout reset time: 73208 ms ago
  Wakelock ref count: 0
  # of events on pending write queue: 0
  # of non-dynamic sensors across all subhals: 8
  # of dynamic sensors across all subhals: 0
SubHals (2):
  Name: FakeSubHal-OnChange
  Debug dump:
Available sensors:
Name: Ambient Temp Sensor
Min delay: 40000
Flags: 2
Name: Light Sensor
Min delay: 200000
Flags: 2
Name: Proximity Sensor
Min delay: 200000
Flags: 3
Name: Relative Humidity Sensor
Min delay: 40000
Flags: 2
  Name: FakeSubHal-OnChange
  Debug dump:
Available sensors:
Name: Ambient Temp Sensor
Min delay: 40000
Flags: 2
Name: Light Sensor
Min delay: 200000
Flags: 2
Name: Proximity Sensor
Min delay: 200000
Flags: 3
Name: Relative Humidity Sensor
Min delay: 40000
Flags: 2

Si el número especificado para # of events on pending write queue es un número grande (1,000 o más), significa que hay muchos eventos pendientes de escribir en el framework de sensores. Esto indica que el servicio del sensor está interbloqueado o falló y no procesa eventos de sensores, o que un gran lote de eventos de sensores publicado recientemente desde una subHAL.

Si el recuento de referencias de bloqueo de activación es mayor que 0, significa que HalProxy adquirió un bloqueo de activación. Solo debe ser mayor que 0 si se mantiene un ScopedWakelock de forma intencional o si se enviaron eventos de activación a HalProxy y el framework de sensores no los procesó.

El descriptor de archivos que se pasa al método de depuración de HalProxy se pasa a cada sub-HAL, por lo que los desarrolladores deben implementar el método de depuración como parte de la interfaz ISensorsSubHal.