En la siguiente figura, se representa la pila de sensores de Android. Cada componente se comunica solo con los componentes que están directamente arriba y debajo de él, aunque algunos sensores pueden omitir el concentrador de sensores cuando está presente. El control fluye de las aplicaciones a los sensores, y los datos fluyen de los sensores a las aplicaciones.
Figura 1: Capas de la pila de sensores de Android y sus respectivos propietarios
SDK
Las aplicaciones acceden a los sensores a través de la API del SDK (kit de desarrollo de software) de sensores. El SDK contiene funciones para enumerar los sensores disponibles y registrarse en un sensor.
Cuando se registra en un sensor, la aplicación especifica su frecuencia de muestreo y sus requisitos de latencia preferidos.
- Por ejemplo, una aplicación podría registrarse en el acelerómetro predeterminado, solicitar eventos a 100 Hz y permitir que los eventos se informen con una latencia de 1 segundo.
- La aplicación recibirá eventos del acelerómetro a una velocidad de al menos 100 Hz y, posiblemente, con una demora de hasta 1 segundo.
Consulta la documentación para desarrolladores para obtener más información sobre el SDK.
Framework
El framework se encarga de vincular las varias aplicaciones al HAL. El HAL es de un solo cliente. Sin esta multiplexación a nivel del marco de trabajo, solo una aplicación podría acceder a cada sensor en un momento determinado.
- Cuando una primera aplicación se registra en un sensor, el framework envía una solicitud al HAL para activarlo.
- Cuando se registran aplicaciones adicionales en el mismo sensor, el framework tiene en cuenta los requisitos de cada aplicación y envía los parámetros solicitados actualizados al HAL.
- La frecuencia de muestreo será la máxima de las frecuencias de muestreo solicitadas, lo que significa que algunas aplicaciones recibirán eventos con una frecuencia superior a la que solicitaron.
- La latencia máxima de los informes será la mínima de las solicitadas. Si una aplicación solicita un sensor con una latencia máxima de informes de 0, todas las aplicaciones recibirán los eventos de este sensor en modo continuo, incluso si algunas solicitaron el sensor con una latencia máxima de informes distinta de cero. Consulta Ejecución por lotes para obtener más detalles.
- Cuando la última aplicación registrada en un sensor se da de baja, los frameworks envían una solicitud al sistema HAL para desactivar el sensor, de modo que no se consuma energía de forma innecesaria.
Impacto de la multiplexación
Esta necesidad de una capa de multiplexación en el framework explica algunas decisiones de diseño.
- Cuando una aplicación solicita una frecuencia de muestreo específica, no hay garantía de que los eventos no lleguen a una velocidad más rápida. Si otra aplicación solicitó el mismo sensor a una velocidad más rápida, la primera aplicación también lo recibirá a la velocidad rápida.
- La misma falta de garantía se aplica a la latencia máxima de informes solicitada: las aplicaciones pueden recibir eventos con mucha menos latencia de la que solicitaron.
- Además de la frecuencia de muestreo y la latencia máxima de informes, las aplicaciones no pueden configurar los parámetros del sensor.
- Por ejemplo, imagina un sensor físico que pueda funcionar en los modos de "alta precisión" y "bajo consumo".
- Solo se puede usar uno de esos dos modos en un dispositivo Android, ya que, de lo contrario, una aplicación podría solicitar el modo de alta precisión y otra un modo de bajo consumo. El framework no podría satisfacer ambas aplicaciones. El framework siempre debe poder satisfacer a todos sus clientes, por lo que esta no es una opción.
- No hay un mecanismo para enviar datos de las aplicaciones a los sensores ni a sus controladores. Esto garantiza que una aplicación no pueda modificar el comportamiento de los sensores, lo que dañaría otras aplicaciones.
Fusión de sensores
El framework de Android proporciona una implementación predeterminada para algunos sensores compuestos. Cuando un dispositivo tiene un giroscopio, un acelerómetro y un magnetómetro, pero no tiene sensores de vector de rotación, gravedad ni aceleración lineal, el framework implementa esos sensores para que las aplicaciones puedan usarlos.
La implementación predeterminada no tiene acceso a todos los datos a los que tienen acceso otras implementaciones y debe ejecutarse en el SoC, por lo que no es tan precisa ni tan eficiente en el consumo de energía como otras implementaciones. En la medida de lo posible, los fabricantes de dispositivos deben definir sus propios sensores fusionados (vector de rotación, gravedad y aceleración lineal, así como sensores compuestos más nuevos, como el vector de rotación de juegos), en lugar de depender de esta implementación predeterminada. Los fabricantes de dispositivos también pueden solicitar a los proveedores de chips de sensores que les proporcionen una implementación.
La implementación predeterminada de la fusión de sensores no se mantiene y podría hacer que los dispositivos que dependen de ella no cumplan con CTS.
Bajo la superficie
Esta sección se proporciona como información de referencia para quienes mantienen el código del framework del Proyecto de código abierto de Android (AOSP). No es relevante para los fabricantes de hardware.
JNI
El framework usa una interfaz nativa de Java (JNI) asociada con android.hardware y ubicada en el directorio frameworks/base/core/jni/. Este código llama al código nativo de nivel inferior para obtener acceso al hardware del sensor.
Framework nativo
El framework nativo se define en frameworks/native/ y proporciona un equivalente nativo al paquete android.hardware. El framework nativo llama a los proxies de IPC de Binder para obtener acceso a los servicios específicos del sensor.
IPC de Binder
Los proxies de IPC de Binder facilitan la comunicación a través de los límites del proceso.
HAL
La API de la capa de abstracción de hardware (HAL) de los sensores es la interfaz entre los controladores de hardware y el framework de Android. Consiste en una interfaz de HAL, .h, y una implementación de HAL a la que nos referimos como.cpp.
Los colaboradores de Android y AOSP definen la interfaz, y el fabricante del dispositivo proporciona la implementación.
La interfaz de la HAL del sensor se encuentra en hardware/libhardware/include/hardware.
Consulta sensors.h para obtener más detalles.
Ciclo de lanzamiento
La implementación de HAL especifica qué versión de la interfaz de HAL implementa configurando your_poll_device.common.version. Las versiones existentes de la interfaz de HAL se definen en sensors.h, y la funcionalidad está vinculada a esas versiones.
Actualmente, el framework de Android admite las versiones 1.0 y 1.3, pero la 1.0 dejará de estar disponible pronto. En esta documentación, se describe el comportamiento de la versión 1.3, a la que deben actualizarse todos los dispositivos. Para obtener detalles sobre cómo actualizar a la versión 1.3, consulta Dar de baja la versión de HAL.
Controlador de kernel
Los controladores de sensores interactúan con los dispositivos físicos. En algunos casos, la implementación de HAL y los controladores son la misma entidad de software. En otros casos, el integrador de hardware solicita a los fabricantes de chips de sensores que proporcionen los controladores, pero son ellos quienes escriben la implementación de HAL.
En todos los casos, la implementación de HAL y los controladores de kernel son responsabilidad de los fabricantes de hardware, y Android no proporciona enfoques preferidos para escribirlos.
Concentrador de sensores
De manera opcional, la pila de sensores de un dispositivo puede incluir un concentrador de sensores, que es útil para realizar algunas operaciones de procesamiento de bajo nivel con bajo consumo de energía mientras el SoC puede estar en modo de suspensión. Por ejemplo, el recuento de pasos o la fusión de sensores se pueden realizar en esos chips. También es un buen lugar para implementar el procesamiento por lotes de sensores y agregar FIFO de hardware para los eventos del sensor. Consulta Ejecución por lotes para obtener más información.
Nota: Para desarrollar nuevas funciones de ContextHub que usen LED o sensores nuevos, también puedes usar un Neonkey SensorHub conectado a una placa de desarrollo HiKey o HiKey960.
La forma en que se materializa el concentrador de sensores depende de la arquitectura. A veces, es un chip independiente y, a veces, se incluye en el mismo chip que el SoC. Una característica importante del concentrador de sensores es que debe contener suficiente memoria para el procesamiento por lotes y consumir muy poca energía para permitir la implementación de los sensores de Android de bajo consumo. Algunos concentradores de sensores contienen un microcontrolador para el procesamiento genérico y aceleradores de hardware para habilitar el procesamiento de muy baja potencia para sensores de baja potencia.
Android no especifica cómo está diseñada la arquitectura del concentrador de sensores ni cómo se comunica con los sensores y el SoC (bus I2C, bus SPI, etc.), pero su objetivo debe ser minimizar el uso general de energía.
Una opción que parece tener un impacto significativo en la simplicidad de la implementación es tener dos líneas de interrupción que van del concentrador de sensores al SoC: una para las interrupciones de activación (para sensores de activación) y la otra para las interrupciones que no son de activación (para sensores que no son de activación).
Sensores
Esos son los chips MEMS físicos que realizan las mediciones. En muchos casos, hay varios sensores físicos presentes en el mismo chip. Por ejemplo, algunos chips incluyen un acelerómetro, un giroscopio y un magnetómetro. (Estos chips a menudo se llaman chips de 9 ejes, ya que cada sensor proporciona datos en 3 ejes).
Algunos de esos chips también contienen lógica para realizar cálculos habituales, como la detección de movimiento, la detección de pasos y la fusión de sensores de 9 ejes.
Aunque los requisitos y las recomendaciones de potencia y precisión de la CDD se orientan al sensor de Android y no a los sensores físicos, esos requisitos afectan la elección de los sensores físicos. Por ejemplo, el requisito de precisión en el vector de rotación del juego tiene implicaciones en la precisión requerida para el giroscopio físico. Depende del fabricante del dispositivo derivar los requisitos para los sensores físicos.