La capa de abstracción de hardware de sensores (HAL) es la interfaz entre los un marco de trabajo de sensores de Android y los sensores de un dispositivo, como un acelerómetro o giroscopio. La HAL de sensores define las funciones que deben implementarse para permiten que el framework controle los sensores.
La HAL de sensores AIDL está disponible en Android 13 y más alto para dispositivos nuevos y actualizados. La HAL del AIDL de sensores, que se basa en La HAL de sensores 2.1 usa la la interfaz de la HAL del AIDL y expone el monitor de cabeza y los tipos de sensores IMU de eje limitado.
Interfaz de la HAL del AIDL
La principal fuente de documentación de la HAL del AIDL de sensores se encuentra en la HAL definición en hardware/interfaces/sensors/aidl/android/hardware/sensors/ISensors.aidl.
Implementa la HAL del AIDL de sensores
Para implementar la HAL del AIDL de sensores, un objeto debe extender el ISensors
e implementar todas las funciones definidas en
hardware/interfaces/sensors/aidl/android/hardware/sensors/ISensors.aidl.
Cómo inicializar la HAL
El framework del sensor de Android debe inicializar la HAL de sensores antes de
un modelo de AA. El framework llama a la función initialize() para proporcionar tres
parámetros a la HAL de sensores: dos descriptores de FMQ y un puntero a una
ISensorsCallback.
La HAL usa el primer descriptor para crear el evento FMQ que se usa para escribir el sensor
eventos al framework. La HAL usa el segundo descriptor para crear la alerta de activación
Bloqueo de FMQ que se usa para sincronizar cuando la HAL libera el bloqueo de activación para WAKE_UP
de sensores. La HAL debe guardar un puntero en el objeto ISensorsCallback para que
que se pueden invocar las funciones de devolución de llamada necesarias.
La función initialize() debe ser la primera a la que se llama durante la inicialización
la HAL de sensores.
Cómo exponer los sensores disponibles
Para obtener una lista de todos los sensores estáticos disponibles en el dispositivo, usa el
función getSensorsList(). Esta función muestra una lista de sensores, cada uno
que se identifica de forma única
por su identificador. El controlador de un sensor determinado no debe cambiar
cuando se reinicia el proceso que aloja la HAL de sensores. Los identificadores pueden cambiar
y entre reinicios del servidor del sistema.
Si varios sensores comparten el mismo tipo de sensor y propiedad de activación, la
primer sensor de la lista se llama sensor predeterminado y se devuelve al
apps que usan getDefaultSensor(int sensorType, bool wakeUp)
.
Estabilidad de la lista de sensores
Después de que se reinicia la HAL de sensores, si los datos devueltos por getSensorsList()
indica un cambio significativo en comparación con la lista de sensores recuperada antes del
reiniciar, el framework activa un reinicio de la
Tiempo de ejecución de Android Los cambios significativos en la lista de sensores incluyen casos en los que un
sensor con un controlador determinado si falta o ha cambiado atributos, o cuando se usa un
se introducen sensores. Aunque reiniciar el tiempo de ejecución de Android es disruptivo
para el usuario, es necesario porque el framework de Android ya no puede cumplir
la API de Android contratan que los sensores estáticos (no dinámicos) no cambien durante la
el ciclo de vida de una app. Esto también puede impedir que el framework se restablezca
solicitudes de sensores activas que realizan las apps. Por lo tanto, se recomienda a los proveedores de HAL
para evitar cambios evitables en la lista de sensores.
Para garantizar controladores estables del sensor, el HAL debe asignar de manera determinista un del sensor físico del dispositivo al mango. Aunque no se requiere una implementación específica la interfaz de la HAL de sensores, los desarrolladores tienen diversas opciones disponibles para cumplir con este requisito.
Por ejemplo, la lista de sensores puede ordenarse combinando las señales de
atributos fijos, como proveedor, modelo y tipo de sensor. Otra opción se basa en
el conjunto de sensores
estáticos del dispositivo es fijo en el hardware,
La HAL debe saber cuándo todos los sensores esperados completaron la inicialización antes
que regresan de getSensorsList(). Esta lista de
los sensores esperados pueden compilarse en el objeto binario de HAL o almacenarse en una
de configuración en el sistema de archivos y se puede usar el orden de aparición
para obtener controladores estables. Aunque la mejor solución depende del estado
detalles específicos de la implementación, el requisito clave es que el sensor se ocupe
no cambien en los reinicios del HAL.
Configurar sensores
Antes de activar un sensor, este se debe configurar con un modelo
y la latencia máxima de los informes con la función batch().
Un sensor se debe poder reconfigurar en cualquier momento mediante batch() sin la
pérdida de datos de sensores.
Período de muestreo
El período de muestreo tiene un significado diferente según el tipo de sensor que se utilice. que se está configurando:
- Continuo: Los eventos de sensores se generan a una velocidad continua.
- Si se produce un cambio: Los eventos se generan antes del período de muestreo y pueden generados a una tasa más lenta que el período de muestreo si el valor medido no cambia.
- Única: Se ignora el período de muestreo.
- Especial: Para obtener más detalles, consulta Tipos de sensores.
Para aprender sobre la interacción entre un período de muestreo y el estado modos de generación de informes, consulte Modos de informes.
Latencia de informes máxima
La latencia máxima de los informes establece el tiempo máximo en nanosegundos pueden demorarse y almacenarse en el FIFO de hardware antes de escribirse el FMQ del evento a través de la HAL mientras el SoC está activo.
Un valor de cero significa que los eventos se deben informar medirse, ya sea omitiendo el FIFO por completo o vaciado el FIFO tan pronto como un evento del sensor está presente en el FIFO.
Por ejemplo, un acelerómetro activado a 50 Hz con un máximo de informes latencia de cero activa interrupciones 50 veces por segundo cuando el SoC está activo.
Cuando la latencia máxima de informe es mayor que cero, los eventos del sensor no se deben informar apenas se detectan. Los eventos se pueden se almacenan en el FIFO de hardware y se informan en lotes, siempre que no se produzca retrasado por más que la latencia de informe máxima. Todos los eventos desde el lote anterior se registran y se devuelven de una sola vez. Esto reduce la cantidad de Interrupciones enviadas al SoC y permiten que este cambie a un modo de bajo consumo mientras el sensor captura y procesa los datos en lotes.
Cada evento tiene una marca de tiempo asociada. Retrasar el momento en el que un el evento que se informa no debe afectar la marca de tiempo del evento. La marca de tiempo debe ser sean precisos y correspondan a la hora a la que ocurrió físicamente el evento, no la hora en que se informó.
Para obtener información y requisitos adicionales sobre cómo informar eventos de sensores con de informes máxima distinta de cero, consulta Agrupación en lotes.
Activar sensores
El framework habilita e inhabilita los sensores con la función activate().
Antes de activar un sensor, el framework primero debe configurar el sensor
usando batch().
Después de desactivar un sensor, los eventos de sensores adicionales de ese sensor no deben escribirse en la FMQ del evento.
Limpiar sensores
Si un sensor está configurado para agrupar los datos del sensor, el framework puede forzar
una limpieza inmediata de eventos de sensores por lotes llamando a flush(). Esto provoca
que los eventos del sensor por lotes para el controlador del sensor especificado se envíen inmediatamente
se escribe en el FMQ del evento. La HAL de sensores debe agregar un evento de vaciado completo.
hasta el final de los eventos de sensores que se escriben como resultado de una llamada a
flush()
La limpieza ocurre de forma asíncrona (es decir, esta función debe mostrar inmediatamente). Si la implementación usa un único FIFO para varios sensores, ese FIFO se limpia y el evento de vaciado completo se agrega solo para el sensor especificado.
Si el sensor especificado no tiene FIFO (no hay almacenamiento en búfer posible) o si el FIFO no
vacío en el momento de la llamada, flush() aún debe tener éxito y enviar un vaciado
evento completo para ese sensor. Esto se aplica a todos los sensores, excepto a los de un intento.
sensores.
Si se llama a flush() para un sensor único, flush() debe devolverse.
BAD_VALUE y no generan un evento de vaciado completo.
Escribe los eventos del sensor en el FMQ
La HAL de sensores usa el FMQ de eventos para enviar eventos de sensores a Android del marco de trabajo del sensor.
El FMQ del evento es una FMQ sincronizada, lo que significa que cualquier intento de escribir más eventos a FMQ antes de que el espacio disponible permita resultados escribir. En ese caso, la HAL debe determinar si debe escribir el conjunto actual de eventos como dos grupos más pequeños de eventos o para escribir todos los eventos cuando hay suficiente espacio disponible.
Cuando la HAL de sensores ha escrito la cantidad deseada de eventos de sensores en el
FMQ de evento, la HAL de sensores debe notificar al framework que los eventos están listos
escribiendo el bit EventQueueFlagBits::READ_AND_PROCESS al evento FMQ
Función EventFlag::wake. El EventFlag se puede crear desde el Event FMQ
con EventFlag::createEventFlag y el getEventFlagWord() de Event FMQ
.
La HAL del AIDL de sensores admite write y writeBlocking en el evento FMQ.
La implementación predeterminada proporciona una referencia para usar write. Si el botón
writeBlocking, la marca readNotification debe establecerse en
EventQueueFlagBits::EVENTS_READ, que establece el framework cuando lee
del evento FMQ. La marca de notificación de escritura debe establecerse en
EventQueueFlagBits::READ_AND_PROCESS, que notifica al framework que los eventos
se hayan escrito en el FMQ del evento.
Eventos WAKE_UP
Los eventos WAKE_UP son eventos de sensores que provocan que el procesador de la aplicación (AP)
activar y controlar el evento de inmediato. Cada vez que se escribe un evento WAKE_UP
al FMQ de evento, la HAL de sensores debe asegurar un bloqueo de activación para garantizar que
hasta que el framework pueda controlar el evento. Al recibir un
WAKE_UP, el framework protege su propio bloqueo de activación, lo que permite
Detecta la HAL para liberar el bloqueo de activación. Para sincronizar el momento en que la HAL de sensores
libera su bloqueo de activación, utiliza el FMQ Wake Lock.
La HAL de sensores debe leer el FMQ del bloqueo de activación para determinar la cantidad de WAKE_UP
eventos que el framework manejó. La HAL solo debería liberar su bloqueo de activación
para los eventos WAKE_UP si la cantidad total de eventos WAKE_UP no controlados es cero
Después de controlar los eventos de sensores, el framework cuenta el número de eventos que se
marcado como eventos WAKE_UP y vuelve a escribir este número en el FMQ de Wake Lock.
El framework establece la operación de escritura WakeLockQueueFlagBits::DATA_WRITTEN
en la FMQ de Wake Lock cuando se escriben datos en el FMQ de Wake Lock.
Sensores dinámicos
Los sensores dinámicos son aquellos que no forman parte física del dispositivo, pero que pueden usarse como entrada para el dispositivo, como un control de juegos con un acelerómetro.
Cuando se conecta un sensor dinámico, la función onDynamicSensorConnected en
Se debe llamar a ISensorsCallback desde la HAL de sensores. Esto notifica al
del nuevo sensor dinámico y permite que este se controle
a través del framework y que los clientes consuman los eventos del sensor.
De forma similar, cuando se desconecta un sensor dinámico, el
Se debe llamar a la función onDynamicSensorDisconnected en ISensorsCallback
que el marco pueda quitar 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
una memoria específica en lugar de la FMQ del evento sin pasar por los sensores Android
de Google Cloud. 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 framework. El configDirectReport()
es similar a batch() para el funcionamiento normal y configura el
canal de informes.
Las funciones registerDirectChannel() y unregisterDirectChannel() crean
o destruir un canal directo nuevo.
Modos de operación
La función setOperationMode() permite que el framework configure un sensor
para que el framework pueda inyectar datos del sensor en el sensor. Esto es útil para
en especial para los algoritmos que existen debajo del framework.
La función injectSensorData() se usa normalmente para enviar
parámetros en la HAL de sensores. La función también se puede usar para inyectar el sensor
eventos en un sensor específico.
Validación
Para validar tu implementación de la HAL de sensores, ejecuta los CTS y el VTS del sensor y pruebas.
Pruebas del CTS
Las pruebas del CTS del sensor existen tanto en pruebas automatizadas del CTS como en el verificador del CTS manual .
Las pruebas automatizadas se encuentran cts/tests/sensor/src/android/hardware/cts Estas pruebas verifican la funcionalidad estándar de los sensores, como la activación sensores, procesamiento por lotes y tasas de eventos de sensores.
Las pruebas del verificador del CTS se encuentran en cts/apps/CtsVerifier/src/com/android/cts/verifier/sensors Estas pruebas requieren la entrada manual del operador para garantizar que los sensores registran valores precisos.
Aprobar las pruebas del CTS es fundamental para garantizar que el dispositivo sometido a prueba cumpla con todos los requisitos de CDD.
Pruebas de VTS
Las pruebas de VTS para la HAL de sensores AIDL se encuentran en
hardware/interfaces/sensors/aidl/vts/;
Estas pruebas garantizan que la HAL de sensores esté implementada correctamente y que todas
de los requisitos de ISensors.aidl y ISensorsCallback.aidl se cumplan correctamente.
Cómo inicializar la HAL
La función initialize() debe ser compatible para establecer FMQ entre las
el framework y la HAL.
Cómo exponer los sensores disponibles
En la HAL del AIDL de sensores, la función getSensorsList() debe mostrar el mismo valor
durante el inicio de un solo dispositivo, incluso entre reinicios de la HAL de sensores. Un requisito nuevo
de la función getSensorsList() es que debe mostrar el mismo valor durante
de un solo dispositivo, incluso entre reinicios de la HAL de sensores. Esto permite que los
para intentar restablecer las conexiones de los sensores si el servidor del sistema
reinicios. El valor que muestra getSensorsList() puede cambiar después de que se activa el dispositivo.
realiza un reinicio.
Escribe los eventos del sensor en el FMQ
En lugar de esperar a que se llame a poll(), en la HAL del AIDL de Sensores, los sensores
La HAL debe escribir de forma proactiva los eventos del sensor en la FMQ del evento cada vez que se produce algún evento.
están disponibles. La HAL también se encarga de escribir los bits correctos en
EventFlag para provocar que se lea una FMQ dentro del framework.
Eventos WAKE_UP
En la HAL de sensores 1.0, la HAL pudo liberar su bloqueo de activación para cualquier WAKE_UP
evento en cualquier llamada posterior a poll() después de que se publicara un WAKE_UP en
poll() porque indica que el framework procesó todos los sensores
eventos y había obtenido un bloqueo de activación, si fuera necesario. Porque, en el AIDL de Sensors,
HAL, ya no se notifica a la HAL cuando el framework procesa eventos
escrito en la FMQ, Wake Lock FMQ permite que el framework se comunique con el
HAL cuando controló eventos de WAKE_UP.
En la HAL del AIDL de sensores, el bloqueo de activación protegido por la HAL de sensores de WAKE_UP
los eventos deben comenzar con SensorsHAL_WAKEUP.
Sensores dinámicos
Se mostraron los sensores dinámicos con la función poll() en la HAL de sensores 1.0.
La HAL del AIDL de sensores requiere que onDynamicSensorsConnected y
Se puede llamar a onDynamicSensorsDisconnected en ISensorsCallback siempre que sea dinámico
las conexiones de los sensores cambian. Estas devoluciones de llamada están disponibles como parte del
Puntero ISensorsCallback proporcionado a través de la función initialize().
Modos de operación
El modo DATA_INJECTION para los sensores WAKE_UP debe ser compatible.
Compatibilidad con varias HAL
La HAL del AIDL de sensores admite varias HAL con el Framework de varias HAL de sensores. Para detalles de la implementación, consulta Portabilidad de la HAL de sensores 2.1.