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

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. Sensores HAL 2.0 está basado en sensores HAL 1.0 pero tiene varias diferencias clave, que impiden ser compatible hacia atrás. Utiliza sensores HAL 2.0 Fast colas de mensajes (FMQs) para enviar los eventos de sensor de la HAL en el marco 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 Sensores HAL 2.0 que expone la HINGE_ANGLE tipo de sensor y actualiza varios métodos para aceptar la HINGE_ANGLE tipo.

Interfaz HAL 2.1

La principal fuente de documentación para Sensores HAL 2.1 está dentro de la definición de HAL en el hardware / las interfaces / sensores / 2.1 / ISensors.hal . Si hay un conflicto de requisitos entre esta página y ISensors.hal , utilice el requisito de ISensors.hal .

Interfaz HAL 2.0

La principal fuente de documentación para Sensores HAL 2.0 está dentro de la definición HAL en hardware / interfaces de / sensores / 2,0 / ISensors.hal . Si hay un conflicto de requisitos entre esta página y ISensors.hal , utilice el requisito de ISensors.hal .

Implementación de sensores HAL 2.0 y HAL 2.1

La implementación de sensores HAL 2.0 o 2.1, un objeto debe extender el ISensors interfaz 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 al initialize() función para HAL 2,0 y el initialize_2_1() función para HAL 2,1 para proporcionar tres parámetros a los sensores HAL: dos FMQ descriptores y un puntero a un ISensorsCallback objeto.

El HAL utiliza el primer descriptor para crear el evento FMQ utilizado para escribir eventos de sensor en el marco. El HAL utiliza el segundo descriptor para crear la Wake Lock FMQ utiliza para sincronizar cuando el HAL libera su bloqueo a raíz de WAKE_UP eventos del sensor. El HAL debe guardar un puntero a la ISensorsCallback objeto de manera que cualquier función de devolución de llamada necesarias pueden ser invocados.

El initialize() o initialize_2_1() la función 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, utilice el getSensorsList() función en HAL 2,0 y getSensorsList_2_1() función 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 la propiedad de despertador, entonces el primer sensor en la lista se llama el sensor defecto y se devuelve a las aplicaciones que utilizan el getDefaultSensor(int sensorType, bool wakeUp) función.

Estabilidad de la lista de sensores

Después de un reinicio Sensores HAL, si los datos devueltos por getSensorsList() o getSensorsList_2_1() indica un cambio significativo en comparación con la lista de sensores recuperado antes del reinicio, el marco provoca 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 sensor activas 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 conjunto de sensores estáticos del dispositivo se fija en el hardware, por lo que el HAL necesita saber cuándo se espera que todos los sensores han completado la inicialización antes de volver de getSensorsList() o getSensorsList_2_1() . Esta lista de sensores esperados puede compilarse en el binario HAL o almacenarse en un archivo de configuración en el sistema de archivos, y el orden de aparición puede usarse 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 activa un sensor, el sensor debe estar configurado con un periodo de muestreo y máxima notificación de latencia usando el batch() función.

Un sensor debe ser capaz de ser reconfigurado en cualquier momento usando 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 más detalles, ver los tipos de sensores .

Para obtener información sobre la interacción entre un periodo de muestreo y los modos de presentación de informes de un sensor, ver Reporting modos .

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 miden, 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 más información y requisitos de presentación de informes de eventos del sensor con la máxima distinto de cero latencia informes adicionales, consulte Preparación de lotes .

Activar sensores

El marco activa y desactiva los sensores utilizando el activate() función. Antes de la activación de 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 los datos del sensor de lotes, el marco puede forzar una descarga inmediata de eventos del sensor por lotes llamando 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 de HAL debe añadir un evento completo al ras con el final de los eventos de 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 no tiene ningún otro FIFO (sin almacenamiento temporal es posible), o si la FIFO estaba vacío en el momento de la llamada, flush() todavía debe tener éxito y enviar un evento completo de descarga para ese sensor. Esto se aplica a todos los sensores que no sean de un disparo.

Si flush() se llama para un sensor de un solo disparo, entonces flush() debe devolver BAD_VALUE y no genera un evento completo ras.

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 los sensores HAL ha escrito el número deseado de los sensores a los eventos FMQ evento, los sensores HAL debe notificar al marco que los eventos están listos escribiendo el EventQueueFlagBits::READ_AND_PROCESS poco a FMQ del Evento EventFlag::wake función. El EventFlag puede ser creado a partir de la FMQ eventos mediante EventFlag::createEventFlag del FMQ de eventos y getEventFlagWord() función.

Sensores HAL 2.0 / 2.1 soporta tanto write y writeBlocking en el FMQ Evento. La implementación por defecto proporciona una referencia para el uso de write . Si el writeBlocking se utiliza la función, la readNotification la opción debe ser a EventQueueFlagBits::EVENTS_READ , que es fijado por el marco cuando se lee eventos de la FMQ Evento. La bandera de notificación de escritura se debe establecer en EventQueueFlagBits::READ_AND_PROCESS , que notifica el marco que los acontecimientos se han escrito a la FMQ Evento.

Eventos de WAKE_UP

WAKE_UP eventos son eventos de sensor que causan el procesador de aplicaciones (AP) para despertar y controlar el evento inmediatamente. Cada vez que un WAKE_UP caso se escribe en el FMQ evento, los sensores HAL debe asegurar un bloqueo de raíz para asegurar que las estancias del sistema despiertan hasta que el marco puede controlar el evento. Al recibir una WAKE_UP caso, el marco asegura su propia estela de bloqueo, lo que permite que los sensores HAL para liberar su bloqueo estela. Para sincronizar cuando el sensor HAL libera su bloqueo de activación, utilice el FMQ de activación de activación.

Los sensores de HAL debe leer la Wake Lock FMQ para determinar el número de WAKE_UP eventos que el marco ha manejado. El HAL sólo debe liberar su bloqueo a raíz de WAKE_UP eventos si el número total de no controladas WAKE_UP eventos es cero. Después de manejar los eventos de sensor, el marco cuenta el número de eventos que están marcados como WAKE_UP eventos y escribe este número de devolución de la Wake Lock FMQ.

El marco establece la WakeLockQueueFlagBits::DATA_WRITTEN notificación de escritura en el Wake Lock FMQ cada vez que escribe datos en el 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.

Del mismo modo, cuando se desconecta un sensor dinámico, el onDynamicSensorDisconnected función en ISensorsCallback debe ser llamado para que el marco puede 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 de los sensores 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. El configDirectReport() función es similar a batch() para el funcionamiento normal y configura el canal informe directo.

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

Modos de operación

El setOperationMode() función permite que el marco para configurar un sensor de manera que el marco puede inyectar datos de sensor en el sensor. Esto es útil para las pruebas, especialmente para los algoritmos que existen debajo del marco.

El injectSensorData() función en HAL 2,0 y injectSensorsData_2_1() función en HAL 2.0 se utiliza normalmente para empujar los parámetros de funcionamiento en los sensores de 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.

Los ensayos automatizados se encuentran en cts / pruebas / sensor / src / androide / 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 CTS Verifier se encuentran en cts / aplicaciones / CtsVerifier / src / com / android / cts / verificador / sensores . 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

Pruebas VTS para Sensores HAL 2.0 se encuentran en hardware / interfaces / sensores / 2.0 / VTS . Pruebas VTS para Sensores HAL 2.1 se encuentran en hardware / interfaces / sensores / 2,1 / VTS . Estas pruebas aseguran que los sensores HAL se aplique correctamente y que todos los requisitos dentro de ISensors.hal y ISensorsCallback.hal se cumplan correctamente.

Actualización a los sensores HAL 2.1 desde 2.0

Cuando se actualiza a Sensores HAL 2,1 de 2,0, su aplicación HAL debe incluir la initialize_2_1() , getSensorsList_2_1() , y injectSensorsData_2_1() métodos, 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 un ejemplo de cómo poner en práctica sus propios sensores 2.1 HAL, ver 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

El initialize() función debe ser apoyado para establecer FMQs entre el marco y HAL.

Exponer los sensores disponibles

En los sensores HAL 2,0, la getSensorsList() función debe devolver el mismo valor durante un solo dispositivo de arranque, incluso a través de reinicios Sensores de HAL. Un nuevo requisito de la getSensorsList() función es que debe devolver el mismo valor durante un solo dispositivo de arranque, incluso a través de reinicios Sensores de HAL. 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.

Escribir eventos de sensor en el FMQ

En lugar de esperar a que poll() para ser llamado, en Sensores para HAL 2.0, los sensores HAL debe eventos de sensor de forma proactiva de escritura en el Evento FMQ siempre que los eventos de sensores están disponibles. El HAL también es responsable de escribir los bits correctos para EventFlag para provocar una FMQ leer en el marco.

Eventos de WAKE_UP

En los sensores HAL 1,0, la HAL fue capaz de liberar su bloqueo estela para cualquier WAKE_UP evento en cualquier llamada posterior a poll() después de un WAKE_UP se envió a poll() porque esto indica que el marco había procesado todos los eventos de sensor y había obtenido una wake lock, si es necesario. Debido a que, en los sensores HAL 2.0, el HAL ya no sabe cuando el marco se ha procesado eventos escritos en el FMQ, Wake Lock FMQ permite el marco de comunicar al HAL cuando se ha manejado WAKE_UP eventos.

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

Sensores dinámicos

Sensores dinámicos fueron devueltos usando el poll() función en Sensores HAL 1.0. Sensores HAL 2.0 requiere que onDynamicSensorsConnected y onDynamicSensorsDisconnected en ISensorsCallback ser llamados cada vez cambio dinámico de conexiones del sensor. Estas devoluciones de llamada están disponibles como parte de la ISensorsCallback puntero que se proporciona a través de la initialize() función.

Modos de operación

El DATA_INJECTION modo para WAKE_UP sensores debe ser apoyada en Sensores HAL 2.0.

Soporte Multi-HAL

Sensores HAL 2.0 y 2.1 soporta multi-HAL utilizando el marco de sensores múltiples HAL . Para detalles de implementación, consulte Trasladar a partir de sensores HAL 1.0 .