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

Sensores Multi-HAL

Sensors Multi-HAL es un marco que permite que los sensores HAL se ejecuten junto con otros sensores HAL. Sensors Multi-HAL carga dinámicamente los sensores sub-HAL almacenados como bibliotecas dinámicas en la partición del proveedor y les proporciona un objeto de devolución de llamada que puede manejar la publicación de eventos y adquirir y liberar el bloqueo de activación. Un sensor sub-HAL es un sensor HAL que está integrado en un objeto compartido en la partición del proveedor y es utilizado por el marco multi-HAL. Estos sub-HAL no dependen unos de otros ni del código multi-HAL que contiene la función principal del proceso.

Sensores Multi-HAL 2.1, disponible en dispositivos con Android 11 o superior, es una iteración de Sensores Multi-HAL 2.0 que los soportes de carga sub-HAL que pueden exponer el ángulo para bisagra tipo de sensor. Para apoyar este tipo de sensor, sub-HAL deben utilizar las API de sub-HAL definidos en el encabezado de 2,1 SubHal .

Diferencia entre los sensores Multi-HAL 2 y los sensores HAL 2

Sensores multi-HAL 2, disponible en dispositivos con Android 10 o superior, introduce varias abstracciones en la parte superior de sensores HAL 2 para que sea más fácil interactuar con las API de HAL. Sensores Multi-HAL 2 introduce la HalProxy clase para controlar la aplicación de la interfaz de sensores HAL 2 y la V2_1/SubHal (o V2_0/SubHal ) interfaz para permitir HalProxy para interactuar con sub-HAL.

El ISensorsSubHal interfaz es diferente de la 2.1/ISensors.hal (o 2.0/ISensors.hal ) interfaz de las siguientes maneras:

  • El método initialize pasa un IHalProxyCallback clase en lugar de dos FMQs 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.
  • Los sub-HAL deben implementar una función de nombre para que el sub-HAL cargado se pueda distinguir de otros sub-HAL.

La principal diferencia entre los sensores Multi-HAL 2 y los sensores HAL 2 está en las funciones de inicialización. En lugar de proporcionar FMQs, la IHalProxyCallback interfaz proporciona dos métodos, un método para publicar eventos de sensores para el marco sensores y un método para crear bloqueos de vigilia. Debajo del capó, Sensors Multi-HAL gestiona todas las interacciones con los FMQ para garantizar la entrega oportuna de eventos de sensores para todos los sub-HAL. Se recomienda encarecidamente que los sub-HAL utilizan el createScopedWakelock método para delegar la carga de tiempo de espera cerraduras estela a los sensores multi-HAL y para centralizar el uso de bloqueo a raíz de una cerradura raíz común para la totalidad de los sensores multi-HAL, lo que minimiza el bloqueo y desbloqueo llamadas.

Sensores Multi-HAL 2 también tiene algunas características de seguridad integradas. Maneja situaciones en las que el sensor FMQ está lleno o en las que el marco del sensor de Android se reinicia y el estado del sensor debe restablecerse. Además, cuando los acontecimientos se publican en la HalProxy clase, pero el marco del sensor es incapaz de aceptar los acontecimientos inmediatamente, los sensores multi-HAL puede mover los eventos a un subproceso de fondo para permitir que el trabajo continúe en todas las sub-HAL a la espera de los acontecimientos para ser publicado.

Implementación de código fuente y referencia

Todo el código sensores multi-HAL está disponible en hardware/interfaces/sensors/common/default/2.X/multihal/ . A continuación, se ofrecen sugerencias para algunos recursos.

  • HalProxy.h : El HalProxy objeto se crea una instancia por los sensores multi-HAL y mangos el paso de los datos de los sub-HAL al marco sensor.
  • HalProxy.cpp : La aplicación de HalProxy contiene toda la lógica necesaria para la comunicación multiplex entre sub-Hals y el marco sensor.
  • SubHal.h : El ISensorsSubHal interfaz define la interfaz que sub-HAL debe seguir para ser compatible con HalProxy . Los implementos sub-HAL el método initialize de modo que el HalProxyCallback objeto se puede utilizar para postEvents y createScopedWakelock .

    Para Multi-HAL 2.0 implementaciones, el uso de la versión 2.0 de SubHal.h .

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

  • hardware/interfaces/sensors/common/default/2.X/multihal/tests/fake_subhal/ : Este ejemplo sub-HAL sensores usos de aplicación falsos para generar datos falsos. Útil para probar cómo interactúan múltiples sub-HAL en un dispositivo.

Implementación

Esta sección describe cómo implementar Sensores Multi-HAL en las siguientes situaciones:

Implementación de sensores Multi-HAL 2.1

Para implementar Sensors Multi-HAL 2.1 en un nuevo dispositivo, siga estos pasos:

  1. Implementar la ISensorsSubHal interfaz como se describe en SubHal.h .
  2. Implementar la sensorsHalGetSubHal_2_1 método en SubHal.h .
  3. Añadir un cc_library_shared objetivo de construir el recién implementado sub-HAL. Al agregar el objetivo:

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

    Para un ejemplo Android.bp entrada para la construcción de una biblioteca de sub-HAL, ver hardware/interfaces/sensors/common/default/2.X/multihal/tests/Android.bp .

  4. Eliminar todos los android.hardware.sensors entradas de la manifest.xml archivo, que contiene la lista de HAL compatibles con el dispositivo.

  5. Eliminar todos los android.hardware.sensors servicio y service.rc archivos de la device.mk archivo y añadir android.hardware.sensors@2.1-service.multihal y android.hardware.sensors@2.1-service.multihal.rc a PRODUCT_PACKAGES .

En el arranque, HalProxy se inicia, busca la reciente aplicación sub-HAL, y lo inicializa llamando sensorsHalGetSubHal_2_1 .

Transferencia de sensores Multi-HAL 2.0 a Multi-HAL 2.1

Al puerto de Multi-HAL 2.0 a 2.1 Multi-HAL, implementar el SubHal interfaz y volver a compilar el sub-HAL.

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

  • IHalProxyCallback utiliza los tipos creados en la versión 2.1 del ISensors.hal specifcation.
  • El initialize() función pasa un nuevo IHalProxyCallback en lugar de la de la 2,0 SubHal interfaz
  • Sub-HAL deben implementar getSensorsList_2_1 y injectSensorData_2_1 en lugar de getSensorsList y injectSensorData ya que estos métodos utilizan los nuevos tipos de agregados en la versión 2.1 de la ISensors.hal especificación.
  • Sub-HAL deben exponer sensorsHalGetSubHal_2_1 en lugar de sensorsHalGetSubHal para el Multi-HAL tratarlos como versión 2.1 sub-HAL.

Portar desde sensores HAL 2.0

Al actualizar a los sensores multi-HAL 2.0 de Sensores HAL 2.0 , garantizar la aplicación HAL cumple los siguientes requisitos.

Inicializando el HAL

Sensores HAL 2.0 tiene una función de inicialización que permite que el servicio del sensor pase los FMQ y una devolución de llamada dinámica del sensor. En los sensores Multi-HAL 2,0, la initialize() función pasa una sola devolución de llamada que debe ser utilizado para publicar eventos de sensor, obtener bloqueos vigilia, y notificar de conexión del sensor dinámico y desconexiones.

Publicar eventos de sensor en la implementación de Multi-HAL

En lugar de publicar los eventos de sensor a través de la FMQ, el sub-HAL debe escribir los sensores a los eventos IHalProxyCallback cuando los eventos de sensores están disponibles.

Eventos de WAKE_UP

En Sensors HAL 2.0, HAL puede gestionar el wake lock para su implementación. En los sensores multi-HAL 2.0, los sub-HAL permiten la ejecución de múltiples HAL el manejo de bloqueos vigilia y pueden solicitar una cerradura de raíz para ser adquirida por la invocación de createScopedWakelock . A raíz de ámbito bloqueado bloqueo debe adquirirse y se pasa a postEvents al publicar llamada de eventos a la aplicación Multi-HAL.

Sensores dinámicos

Sensores multi-HAL 2.0 requiere que onDynamicSensorsConnected y onDynamicSensorsDisconnected en IHalProxyCallback se llaman cada vez que el cambio dinámico de las conexiones del sensor. Estas devoluciones de llamada están disponibles como parte de la IHalProxyCallback puntero que se proporciona a través de la initialize() función.

Transferencia desde sensores HAL 1.0

Cuando se actualiza a Sensores Multi-HAL 2.0 de Sensores HAL 1,0 , garantizar la aplicación HAL cumple los siguientes requisitos.

Inicializando el HAL

El initialize() función debe ser apoyado para establecer la devolución de llamada entre el sub-HAL y la implementación de múltiples HAL.

Exponer los sensores disponibles

En los sensores Multi-HAL 2,0, la getSensorsList() función debe devolver el mismo valor durante un solo dispositivo de arranque, incluso a través de sensores Hal se reinicia. Esto permite que el marco intente restablecer las conexiones del sensor si se reinicia el servidor del sistema. El valor devuelto por getSensorsList() puede cambiar después de que las lleva a cabo un reinicio del dispositivo.

Publicar eventos de sensor en la implementación de Multi-HAL

En Sensores HAL 2.0, en lugar de esperar a que poll() sea llamado, el sub-HAL debe eventos de sensor de forma proactiva de escritura a IHalProxyCallback siempre que los eventos de sensores están disponibles.

Eventos de WAKE_UP

En Sensors HAL 1.0, HAL puede gestionar el bloqueo de activación para su implementación. En los sensores multi-HAL 2.0, los sub-HAL permite la ejecución de múltiples HAL el manejo de bloqueos vigilia y puede solicitar una cerradura de raíz para ser adquirida por la invocación de createScopedWakelock . A raíz de ámbito bloqueado bloqueo debe adquirirse y se pasa a postEvents al publicar llamada de eventos a la aplicación Multi-HAL.

Sensores dinámicos

En los sensores HAL 1,0, sensores dinámicos se devuelven a través de la poll() función. Sensores multi-HAL 2.0 requiere que onDynamicSensorsConnected y onDynamicSensorsDisconnected en IHalProxyCallback se llaman cada vez que el cambio dinámico de las conexiones del sensor. Estas devoluciones de llamada están disponibles como parte de la IHalProxyCallback puntero que se proporciona a través de la initialize() función.

Transferencia desde sensores Multi-HAL 1.0

Al puerto de una implementación existente de sensores multi-HAL 1.0 , siga estos pasos.

  1. Asegúrese de que la configuración de sensores HAL se encuentra en /vendor/etc/sensors/hals.conf. Esto podría implicar mover el archivo que se encuentra en /system/etc/sensors/hals.conf .
  2. Eliminar cualquier referencia a hardware/hardware.h y hardware/sensors.h ya que estos no son compatibles con HAL 2.0.
  3. Port sub-HAL como se describe en Porting de los sensores Hal 1.0 .
  4. Set Sensores Multi-HAL 2.0 como el HAL designado siguiendo los pasos 3 y 4 en el de aplicación Sensores Mutli-HAL 2,0 sección.

Validación

Ejecutando VTS

Cuando se ha integrado una o más sub-HAL con sensores multi-Hal 2.1, utilice el proveedor del conjunto de pruebas (VTS) para asegurar que sus implementaciones sub-HAL cumplen con todos los requisitos establecidos por la interfaz de sensores HAL.

Para ejecutar solo las pruebas de sensores VTS cuando VTS está configurado en una máquina host, ejecute 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

Ejecución de pruebas unitarias

Las pruebas de unidad en HalProxy_test.cpp prueba HalProxy utilizando falsos sub-HAL que se crean instancias en la prueba de unidad y no se cargan de forma dinámica. Al crear una nueva sub-HAL, estas pruebas deben servir como una guía sobre cómo agregar pruebas unitarias que verifiquen que la nueva sub-HAL se implemente correctamente.

Para ejecutar las pruebas, ejecute los siguientes comandos:

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

Prueba con los sub-HAL falsos

Los falso sub-HAL son implementaciones de relleno de las ISensorsSubHal interfaz. Los sub-HAL exponen diferentes listas de sensores. Cuando se activan los sensores, que publican periódicamente eventos de sensor generadas automáticamente a HalProxy en base a los intervalos especificados en una solicitud sensor dado.

Los sub-HAL falsos se pueden usar para probar cómo funciona el código Multi-HAL completo con otros sub-HAL cargados en el sistema y para enfatizar varios aspectos del código Multi-HAL de los sensores.

Dos falsos sub-HAL están disponibles en hardware/interfaces/sensors/common/default/2.X/multihal/tests/fake_subhal/ .

Para crear y enviar los sub-HAL falsos a un dispositivo, realice los siguientes pasos:

  1. Ejecute los siguientes comandos para construir y enviar los tres sub-HAL falsos diferentes 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. Actualizar la HAL sensores config en /vendor/etc/sensors/hals.conf con las rutas de los falsos sub-HAL.

    /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. Restart HalProxy y la carga de los nuevos sub-HAL enumerados en la config.

    adb shell stop
    adb shell start
    

Depuración

Los desarrolladores pueden depurar el marco mediante el uso de la lshal comando. Para solicitar la salida de depuración de los sensores HAL, ejecute el siguiente comando:

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

Información sobre el estado actual de HalProxy y sus sub-HAL es entonces la salida al terminal. A continuación se muestra un ejemplo de la salida del comando para los HalProxy objeto y falsos sub-HAL.

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 de # of events on pending write queue es un número grande (1000 o más), esto indica que hay muchos eventos pendientes que se escriben en el marco sensores. Esto indica que el servicio del sensor está bloqueado o se ha bloqueado y no está procesando los eventos del sensor, o que un gran lote de eventos del sensor se publicó recientemente desde una sub-HAL.

Si el recuento de bloqueos estela ref es mayor que 0 , esto significa HalProxy ha adquirido un bloqueo de paso. Esto sólo debe ser mayor que 0 si un ScopedWakelock intencionalmente está detenido o si los eventos de activación fueron enviados a HalProxy y no han sido procesados por el marco sensor.

El descriptor de archivo se pasa al método de depuración de HalProxy se pasa a cada sub-HAL para que los desarrolladores deben poner en práctica el método de depuración como parte de la ISensorsSubHal interfaz.