Google se compromete a impulsar la igualdad racial para las comunidades afrodescendientes. Obtén información al respecto.
Se usó la API de Cloud Translation para traducir esta página.
Switch to English

Sensores HAL 2

La capa de abstracción de hardware de sensores (HAL) es la interfaz entre el marco de sensores de Android y los sensores de un dispositivo, como un acelerómetro o giroscopio. Los Sensores HAL define las funciones que deben implementarse para permitir que el marco controle los sensores.

Sensors HAL 2.0 está disponible en Android 10 y superior para dispositivos nuevos y actualizados. Sensors HAL 2.0 se basa en Sensors HAL 1.0 pero tiene varias diferencias clave que le impiden ser compatible con versiones anteriores. Sensores HAL 2.0 utiliza Fast Message Queues (FMQ) para enviar eventos de sensor desde HAL al marco de sensor de Android.

Sensors HAL 2.1 está disponible en Android 11 y superior para dispositivos nuevos y actualizados. Sensores HAL 2.1 es una iteración de los sensores HAL 2.0 que expone el tipo de sensor HINGE_ANGLE y actualiza varios métodos para aceptar el tipo HINGE_ANGLE .

Interfaz HAL 2.1

La principal fuente de documentación para Sensors HAL 2.1 se encuentra dentro de la definición de HAL en hardware / interfaces / sensors / 2.1 / ISensors.hal . Si hay un conflicto de requisitos entre esta página e ISensors.hal , utilice el requisito en ISensors.hal .

Interfaz HAL 2.0

La principal fuente de documentación para Sensors HAL 2.0 se encuentra dentro de la definición de HAL en hardware / interfaces / sensors / 2.0 / ISensors.hal . Si hay un conflicto de requisitos entre esta página e ISensors.hal , utilice el requisito en ISensors.hal .

Implementación de sensores HAL 2.0 y HAL 2.1

Para implementar Sensors HAL 2.0 o 2.1, un objeto debe extender la interfaz ISensors e implementar todas las funciones definidas en 2.0/ISensors.hal o 2.1/ISensors.hal .

Inicializando el HAL

Los sensores HAL deben ser inicializados por el marco de sensores de Android antes de que puedan usarse. El marco llama a la función initialize() para HAL 2.0 y la función initialize_2_1() para HAL 2.1 para proporcionar tres parámetros a los sensores HAL: dos descriptores FMQ y un puntero a un objeto ISensorsCallback .

El HAL utiliza el primer descriptor para crear el evento FMQ utilizado para escribir eventos de sensor en el marco. El HAL usa el segundo descriptor para crear el Wake Lock FMQ usado para sincronizar cuando el HAL libera su wake lock para eventos del sensor WAKE_UP . La HAL debe guardar un puntero al objeto ISensorsCallback para que se puedan invocar las funciones de devolución de llamada necesarias.

La función initialize() o initialize_2_1() debe ser la primera función llamada al inicializar los sensores HAL.

Exponer los sensores disponibles

Para obtener una lista de todos los sensores estáticos disponibles en el dispositivo, use la función getSensorsList() en HAL 2.0 y la función getSensorsList_2_1() en HAL 2.1. Esta función devuelve una lista de sensores, cada uno identificado de forma única por su identificador. El mango de un sensor determinado no debe cambiar cuando se reinicia el proceso que aloja los sensores HAL. Los identificadores pueden cambiar entre los reinicios del dispositivo y entre los reinicios del servidor del sistema.

Si varios sensores comparten el mismo tipo de sensor y propiedad de getDefaultSensor(int sensorType, bool wakeUp) el primer sensor de la lista se denomina sensor predeterminado y se devuelve a las aplicaciones que utilizan la función getDefaultSensor(int sensorType, bool wakeUp) .

Estabilidad de la lista de sensores

Después de un reinicio de Sensors HAL, si los datos devueltos por getSensorsList() o getSensorsList_2_1() indican un cambio significativo en comparación con la lista de sensores recuperada antes del reinicio, el marco activa un reinicio del tiempo de ejecución de Android. Los cambios significativos en la lista de sensores incluyen casos en los que un sensor con un mango determinado falta o ha cambiado de atributos, o donde se introducen nuevos sensores. Aunque reiniciar el tiempo de ejecución de Android es perjudicial para el usuario, es necesario porque el marco de Android ya no puede cumplir con el contrato de la API de Android de que los sensores estáticos (no dinámicos) no cambian durante la vida útil de una aplicación. Esto también puede evitar que el marco restablezca las solicitudes de sensores activos realizadas por las aplicaciones. Por lo tanto, se recomienda a los proveedores de HAL que eviten cambios evitables en la lista de sensores.

Para garantizar la estabilidad de los mangos del sensor, el HAL debe asignar de manera determinista un sensor físico dado en el dispositivo a su mango. Aunque la interfaz de Sensors HAL no exige una implementación específica, los desarrolladores tienen varias opciones disponibles para cumplir con este requisito.

Por ejemplo, la lista de sensores se puede ordenar mediante una combinación de los atributos fijos de cada sensor, como el proveedor, el modelo y el tipo de sensor. Otra opción se basa en el hecho de que el conjunto de sensores estáticos del dispositivo está fijo en el hardware, por lo que HAL necesita saber cuándo todos los sensores esperados han completado la inicialización antes de regresar de getSensorsList() o getSensorsList_2_1() . Esta lista de sensores esperados se puede compilar en el binario HAL o almacenar en un archivo de configuración en el sistema de archivos, y el orden de aparición se puede utilizar para derivar identificadores estables. Aunque la mejor solución depende de los detalles de implementación específicos de su HAL, el requisito clave es que los identificadores de los sensores no cambien durante los reinicios de HAL.

Configurar sensores

Antes de que se active un sensor, el sensor debe configurarse con un período de muestreo y una latencia de informe máxima mediante la función batch() .

Un sensor debe poder reconfigurarse en cualquier momento utilizando batch() sin la pérdida de datos del sensor.

Periodo de muestreo

El período de muestreo tiene un significado diferente según el tipo de sensor que se está configurando:

  • Continuo: los eventos del sensor se generan a un ritmo continuo.
  • Al cambiar: los eventos no se generan más rápido que el período de muestreo y pueden generarse a una velocidad más lenta que el período de muestreo si el valor medido no cambia.
  • One-shot: se ignora el período de muestreo.
  • Especial: para obtener más detalles, consulte Tipos de sensores .

Para conocer la interacción entre un período de muestreo y los modos de informe de un sensor, consulte Modos de informe .

Latencia máxima de informes

La latencia máxima de informes establece el tiempo máximo en nanosegundos que los eventos pueden demorarse y almacenarse en el hardware FIFO antes de escribirse en el FMQ de eventos a través de HAL mientras el SoC está activo.

Un valor de cero significa que los eventos deben informarse tan pronto como se midan, ya sea omitiendo el FIFO por completo o vaciando el FIFO tan pronto como un evento del sensor esté presente en el FIFO.

Por ejemplo, un acelerómetro activado a 50 Hz con una latencia de informe máxima de cero dispara interrupciones 50 veces por segundo cuando el SoC está activo.

Cuando la latencia máxima de informes es mayor que cero, no es necesario informar los eventos del sensor tan pronto como se detectan. Los eventos pueden almacenarse temporalmente en el hardware FIFO y notificarse en lotes, siempre que ningún evento se retrase más de la latencia máxima de notificación. Todos los eventos desde el lote anterior se registran y devuelven a la vez. Esto reduce la cantidad de interrupciones enviadas al SoC y permite que el SoC cambie a un modo de menor consumo mientras el sensor captura y procesa datos.

Cada evento tiene una marca de tiempo asociada. Retrasar la hora a la que se informa un evento no debe afectar la marca de tiempo del evento. La marca de tiempo debe ser precisa y corresponder a la hora en la que ocurrió físicamente el evento, no a la hora en que se informó.

Para obtener información adicional y requisitos sobre la notificación de eventos de sensor con una latencia máxima de notificación distinta de cero, consulte Procesamiento por lotes .

Activar sensores

El marco habilita y deshabilita los sensores usando la función activate() . Antes de activar un sensor, el marco debe configurar primero el sensor usando batch() .

Después de que se desactiva un sensor, los eventos de sensor adicionales de ese sensor no deben escribirse en el FMQ de eventos.

Sensores de lavado

Si un sensor está configurado para lotes de datos de sensor, el marco puede forzar un vaciado inmediato de eventos de sensor por lotes llamando a flush() . Esto hace que los eventos de sensor por lotes para el identificador de sensor especificado se escriban inmediatamente en el FMQ de eventos. Los sensores HAL deben agregar un evento flush complete al final de los eventos del sensor que se escriben como resultado de una llamada a flush() .

El vaciado ocurre de forma asincrónica (es decir, esta función debe regresar inmediatamente). Si la implementación usa un solo FIFO para varios sensores, ese FIFO se descarga y el evento de descarga completa se agrega solo para el sensor especificado.

Si el sensor especificado no tiene FIFO (no es posible el almacenamiento en búfer), o si el FIFO estaba vacío en el momento de la llamada, flush() aún debe tener éxito y enviar un evento de flush complete para ese sensor. Esto se aplica a todos los sensores que no sean de un disparo.

Si se llama a flush() para un sensor de un disparo, entonces flush() debe devolver BAD_VALUE y no generar un evento flush complete.

Escribir eventos de sensor en el FMQ

Los sensores HAL utilizan el FMQ de eventos para enviar eventos de sensores al marco de sensores de Android.

El FMQ de eventos es un FMQ sincronizado, lo que significa que cualquier intento de escribir más eventos en el FMQ de los que permite el espacio disponible da como resultado una escritura fallida. En tal caso, la HAL debe determinar si escribir el conjunto actual de eventos como dos grupos más pequeños de eventos o escribir todos los eventos juntos cuando haya suficiente espacio disponible.

Cuando el sensor HAL ha escrito el número deseado de eventos de sensor en el evento FMQ, el sensor HAL debe notificar al marco que los eventos están listos escribiendo el EventQueueFlagBits::READ_AND_PROCESS en la función EventFlag::wake del evento FMQ. El EventFlag se puede crear a partir del Event FMQ usando EventFlag::createEventFlag y la función getEventFlagWord() del Event FMQ.

Los sensores HAL 2.0 / 2.1 admiten tanto el writeBlocking write como el writeBlocking de writeBlocking en el evento FMQ. La implementación predeterminada proporciona una referencia para usar la write . Si se writeBlocking función writeBlocking , el indicador readNotification debe establecerse en EventQueueFlagBits::EVENTS_READ , que es establecido por el marco cuando lee eventos del Event FMQ. El indicador de notificación de escritura debe establecerse en EventQueueFlagBits::READ_AND_PROCESS , que notifica al marco que los eventos se han escrito en el FMQ de eventos.

Eventos de WAKE_UP

WAKE_UP eventos WAKE_UP son eventos de sensor que hacen que el procesador de aplicaciones (AP) se despierte y maneje el evento de inmediato. Siempre que se escribe un evento WAKE_UP en el evento FMQ, los sensores HAL deben asegurar un bloqueo de activación para garantizar que el sistema permanezca activo hasta que el marco pueda manejar el evento. Al recibir un evento WAKE_UP , el marco asegura su propio bloqueo de WAKE_UP , lo que permite que los sensores HAL liberen su bloqueo de activación. Para sincronizar cuando el sensor HAL libera su bloqueo de activación, utilice el FMQ de activación de activación.

Los sensores HAL deben leer Wake Lock FMQ para determinar el número de eventos WAKE_UP que ha manejado el marco. El HAL solo debe liberar su bloqueo de WAKE_UP para eventos WAKE_UP si el número total de eventos WAKE_UP no controlados es cero. Después de manejar los eventos del sensor, el marco cuenta el número de eventos que están marcados como eventos WAKE_UP y escribe este número en Wake Lock FMQ.

El marco establece la notificación de escritura WakeLockQueueFlagBits::DATA_WRITTEN en Wake Lock FMQ cada vez que escribe datos en Wake Lock FMQ.

Sensores dinámicos

Los sensores dinámicos son sensores que no forman parte físicamente del dispositivo, pero que se pueden usar como entrada al dispositivo, como un gamepad con acelerómetro.

Cuando se conecta un sensor dinámico, el onDynamicSensorConnected función en ISensorsCallback debe ser llamado desde los sensores de HAL. Esto notifica al marco del nuevo sensor dinámico y permite que el sensor sea controlado a través del marco y que los clientes consuman los eventos del sensor.

De manera similar, cuando se desconecta un sensor dinámico, se debe llamar a la función onDynamicSensorDisconnected en ISensorsCallback para que el marco pueda eliminar cualquier sensor que ya no esté disponible.

Canal directo

El canal directo es un método de operación en el que los eventos del sensor se escriben en una memoria específica en lugar de en el FMQ de eventos sin pasar por el marco de sensores de Android. Un cliente que registra un canal directo debe leer los eventos del sensor directamente desde la memoria que se usó para crear el canal directo y no recibirá los eventos del sensor a través del marco. La función configDirectReport() es similar a batch() para el funcionamiento normal y configura el canal de informes directos.

Las funciones registerDirectChannel() y unregisterDirectChannel() crean o destruyen un nuevo canal directo.

Modos de operación

La función setOperationMode() permite que el marco configure un sensor para que el marco pueda inyectar datos del sensor en el sensor. Esto es útil para las pruebas, especialmente para los algoritmos que existen debajo del marco.

La función injectSensorData() en HAL 2.0 y la función injectSensorsData_2_1() en HAL 2.0 se usa normalmente para insertar parámetros operativos en Sensors HAL. La función también se puede utilizar para inyectar eventos de sensor en un sensor específico.

Validación

Para validar su implementación de los sensores HAL, ejecute las pruebas del sensor CTS y VTS.

Pruebas CTS

Las pruebas de sensor CTS existen tanto en pruebas CTS automatizadas como en la aplicación CTS Verifier manual.

Las pruebas automatizadas se encuentran en cts / tests / sensor / src / android / hardware / cts . Estas pruebas verifican la funcionalidad estándar de los sensores, como la activación de sensores, el procesamiento por lotes y las tasas de eventos de los sensores.

Las pruebas de CTS Verifier se encuentran en cts / apps / CtsVerifier / src / com / android / cts / verifier / sensers . Estas pruebas requieren la entrada manual del operador de la prueba y garantizan que los sensores informen valores precisos.

Pasar las pruebas CTS es fundamental para garantizar que el dispositivo bajo prueba cumpla con todos los requisitos de CDD.

Pruebas VTS

Las pruebas de VTS para los sensores HAL 2.0 se encuentran en hardware / interfaces / sensores / 2.0 / vts . Las pruebas de VTS para los sensores HAL 2.1 se encuentran en hardware / interfaces / sensores / 2.1 / vts . Estas pruebas garantizan que los sensores HAL se implementen correctamente y que se cumplan correctamente todos los requisitos de ISensors.hal e ISensorsCallback.hal .

Actualización a los sensores HAL 2.1 desde 2.0

Al actualizar a Sensors HAL 2.1 desde 2.0, su implementación de HAL debe incluir los métodos initialize_2_1() , getSensorsList_2_1() e injectSensorsData_2_1() , junto con los tipos HAL 2.1. Estos métodos deben cumplir los mismos requisitos descritos anteriormente para HAL 2.0.

Debido a que los HAL de versiones menores deben admitir todas las funciones de los HAL anteriores, los HAL 2.1 deben admitir que se inicialicen como HAL 2.0. Para evitar la complejidad de admitir ambas versiones de HAL, se recomienda encarecidamente utilizar Multi-HAL 2.1.

Para ver un ejemplo de cómo implementar sus propios Sensors 2.1 HAL, consulte Sensors.h .

Actualización a Sensores HAL 2.0 desde 1.0

Al actualizar a Sensors HAL 2.0 desde 1.0, asegúrese de que su implementación de HAL cumpla con los siguientes requisitos.

Inicializando el HAL

La función initialize() debe ser compatible para establecer FMQ entre el marco y HAL.

Exponer los sensores disponibles

En Sensors HAL 2.0, la función getSensorsList() debe devolver el mismo valor durante el inicio de un solo dispositivo, incluso entre los reinicios de Sensors HAL. Un nuevo requisito de la función getSensorsList() es que debe devolver el mismo valor durante el inicio de un solo dispositivo, incluso entre los reinicios de HAL de Sensors. 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 el dispositivo reinicia.

Escribir eventos de sensor en el FMQ

En lugar de esperar a que se llame a poll() , en los sensores HAL 2.0, los sensores HAL deben escribir eventos de sensor de forma proactiva en el FMQ de eventos siempre que los eventos de sensor estén disponibles. El HAL también es responsable de escribir los bits correctos en EventFlag para provocar una lectura FMQ dentro del marco.

Eventos de WAKE_UP

En Sensors HAL 1.0, HAL pudo liberar su bloqueo de WAKE_UP para cualquier evento WAKE_UP en cualquier llamada posterior a poll() después de que se publicó un WAKE_UP en poll() porque esto indicaba que el marco había procesado todos los eventos del sensor y había obtenido un wake lock, si es necesario. Debido a que, en Sensors HAL 2.0, HAL ya no sabe cuándo el marco ha procesado eventos escritos en FMQ, Wake Lock FMQ permite que el marco se comunique con HAL cuando ha manejado eventos WAKE_UP .

En los sensores HAL 2.0, el bloqueo de WAKE_UP asegurado por los sensores HAL para los eventos WAKE_UP debe comenzar con SensorsHAL_WAKEUP .

Sensores dinámicos

Los sensores dinámicos se devolvieron utilizando la función poll() en Sensors HAL 1.0. Sensors HAL 2.0 requiere que se onDynamicSensorsConnected y onDynamicSensorsDisconnected en ISensorsCallback siempre que cambien las conexiones de los sensores dinámicos. Estas devoluciones de llamada están disponibles como parte del puntero ISensorsCallback que se proporciona a través de la función initialize() .

Modos de operación

El modo DATA_INJECTION para los sensores WAKE_UP debe ser compatible con Sensors HAL 2.0.

Soporte Multi-HAL

Los sensores HAL 2.0 y 2.1 admiten multi-HAL utilizando el marco Sensors Multi-HAL . Para obtener detalles sobre la implementación, consulte Transferencia desde sensores HAL 1.0 .