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 abajo de él, aunque algunos sensores pueden omitir el concentrador de sensores cuando está presente. El control fluye desde las aplicaciones hasta los sensores, y los datos fluyen desde los sensores hasta 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 Sensors. 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 preferida y sus requisitos de latencia.
- Por ejemplo, una aplicación podría registrarse en el acelerómetro predeterminado, solicitar eventos a 100 Hz y permitir que los eventos se registren con una latencia de 1 segundo.
- La aplicación recibirá eventos del acelerómetro a una velocidad de al menos 100 Hz y es posible que se demoren 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 distintas aplicaciones al HAL. El HAL en sí es de un solo cliente. Sin este multiplexado a nivel del framework, 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 activar el sensor.
- 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 mayor que la que solicitaron.
- La latencia máxima de informes será la mínima de las solicitadas. Si una aplicación solicita un sensor con una latencia de informes máxima de 0, todas las aplicaciones recibirán los eventos de este sensor en modo continuo, incluso si algunas solicitaron el sensor con una latencia de informes máxima distinta de cero. Consulta Procesamiento por lotes para obtener más detalles.
- Cuando la última aplicación registrada en un sensor se anula del registro, los frameworks envían una solicitud al 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 los recibirá a esa velocidad.
- 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 puede funcionar en los modos “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, el modo de bajo consumo. No habría forma de que el framework satisfaga a ambas aplicaciones. El framework siempre debe poder satisfacer a todos sus clientes, por lo que esta no es una opción.
- No hay ningún mecanismo para enviar datos desde las aplicaciones a los sensores o sus controladores. Esto garantiza que una aplicación no pueda modificar el comportamiento de los sensores y, de esta manera, interrumpir 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 combinados (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 pasen la CTS.
Bajo la superficie
Esta sección se proporciona como información general 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 Sensors es la interfaz entre los controladores de hardware y el framework de Android. Consta de una interfaz de HAL sensors.h y una implementación de HAL a la que nos referimos como sensors.cpp.
Android y los colaboradores del 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 estableciendo your_poll_device.common.version. Las versiones de interfaz de HAL existentes 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 pronto dejará de admitir la versión 1.0. En esta documentación, se describe el comportamiento de la versión 1.3, a la que se deben actualizar todos los dispositivos. Para obtener detalles sobre cómo actualizar a la versión 1.3, consulta Obsolescencia de la versión del HAL.
Controlador del kernel
Los controladores de sensores interactúan con los dispositivos físicos. En algunos casos, la implementación del 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 es el integrador quien escribe la implementación de la HAL.
En todos los casos, la implementación de HAL y los controladores del kernel son responsabilidad de los fabricantes de hardware, y Android no proporciona enfoques preferidos para escribirlos.
Concentrador de sensores
La pila de sensores de un dispositivo puede incluir, de manera opcional, un concentrador de sensores, que es útil para realizar algunos cálculos de bajo nivel con un consumo de energía bajo mientras el SoC puede estar en modo de suspensión. Por ejemplo, en esos chips se puede realizar el conteo de pasos o la fusión de sensores. También es un buen lugar para implementar el procesamiento por lotes de sensores, ya que se agregan FIFO de hardware para los eventos del sensor. Consulta Procesamiento por lotes para obtener más información.
Nota: Si quieres desarrollar funciones de ContextHub nuevas que usen LED o sensores nuevos, también puedes utilizar un SensorHub de Neonkey 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, otras veces, se incluye en el mismo chip que el SoC. Las características importantes del concentrador de sensores son 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 la computación genérica y aceleradores de hardware para permitir la computación de muy bajo consumo para los sensores de bajo consumo.
Android no especifica cómo se estructura el concentrador de sensores ni cómo se comunica con los sensores y el SoC (bus I²C, bus SPI, etcétera), pero debe intentar 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 los sensores de activación) y la otra para las interrupciones que no son de activación (para los sensores que no son de activación).
Sensores
Esos son los chips de MEMS físicos que realizan las mediciones. En muchos casos, hay varios sensores físicos en el mismo chip. Por ejemplo, algunos chips incluyen un acelerómetro, un giroscopio y un magnetómetro. (Estos chips suelen llamarse 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.
Si bien los requisitos y las recomendaciones de potencia y precisión de la CDD se dirigen 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 del 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.