La siguiente figura representa la pila de sensores de Android. Cada componente se comunica solo con los componentes directamente encima y debajo de él, aunque algunos sensores pueden pasar por alto 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 Sensors SDK (Software Development Kit) . El SDK contiene funciones para enumerar los sensores disponibles y para registrarse en un sensor.
Al registrarse 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 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 un retraso de hasta 1 segundo.
Consulte la documentación del desarrollador para obtener más información sobre el SDK.
Estructura
El marco se encarga de vincular las diversas aplicaciones a la HAL . La propia HAL es de un solo cliente. Sin esta multiplexación a nivel del marco, solo una aplicación podría acceder a cada sensor en un momento dado.
- Cuando una primera aplicación se registra en un sensor, el marco envía una solicitud a la HAL para activar el sensor.
- Cuando se registran aplicaciones adicionales en el mismo sensor, el marco tiene en cuenta los requisitos de cada aplicación y envía los parámetros solicitados actualizados a la 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 solicitada.
- La latencia máxima de reporte será la mínima de las solicitadas. Si una aplicación solicita un sensor con una latencia de informe 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 informe máxima distinta de cero. Consulte Lotes para obtener más detalles.
- Cuando la última aplicación registrada en un sensor cancela su registro, los marcos envían una solicitud a HAL para desactivar el sensor para que la energía no se consuma innecesariamente.
Impacto de la multiplexación
Esta necesidad de una capa de multiplexación en el marco 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 un ritmo más rápido. Si otra aplicación solicitó el mismo sensor a una velocidad más rápida, la primera aplicación también los recibirá a la velocidad más rápida.
- La misma falta de garantía se aplica a la latencia de informes máxima solicitada: las aplicaciones pueden recibir eventos con una latencia mucho menor que la solicitada.
- 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, imagine un sensor físico que pueda funcionar tanto en modo de "alta precisión" como de "baja potencia".
- Solo uno de esos dos modos se puede usar en un dispositivo Android, porque 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 marco satisfaga ambas aplicaciones. El marco siempre debe poder satisfacer a todos sus clientes, por lo que esta no es una opción.
- No existe ningún mecanismo para enviar datos desde las aplicaciones a los sensores o sus controladores. Esto asegura que una aplicación no pueda modificar el comportamiento de los sensores, rompiendo otras aplicaciones.
Fusión de sensores
El marco de trabajo de Android proporciona una implementación predeterminada para algunos sensores compuestos. Cuando un giroscopio , un acelerómetro y un magnetómetro están presentes en un dispositivo, pero no hay sensores de vector de rotación , gravedad y aceleración lineal , el marco implementa esos sensores para que las aplicaciones aún 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 energía como pueden ser 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 del juego ) en lugar de confiar en esta implementación predeterminada. Los fabricantes de dispositivos también pueden solicitar a los proveedores de chips sensores que les proporcionen una implementación.
La implementación predeterminada de la fusión de sensores no se mantiene y puede provocar que los dispositivos que dependen de ella fallen en CTS.
Bajo el capó
Esta sección se proporciona como información básica para aquellos que mantienen el código del marco del Proyecto de código abierto de Android (AOSP). No es relevante para los fabricantes de hardware.
JNI
El marco utiliza 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.
Marco nativo
El marco nativo se define en frameworks/native/ y proporciona un equivalente nativo al paquete android.hardware . El marco nativo llama a los proxies Binder IPC para obtener acceso a servicios específicos del sensor.
Aglutinante CIP
Los proxies Binder IPC facilitan la comunicación más allá de los límites del proceso.
HAL
La API de capa de abstracción de hardware de sensores (HAL) es la interfaz entre los controladores de hardware y el marco de trabajo de Android. Consiste en una interfaz HAL de sensores.h y una implementación de HAL a la que nos referimos como sensores.cpp.
La interfaz la definen los colaboradores de Android y AOSP, y la implementación la proporciona el fabricante del dispositivo.
La interfaz HAL del sensor se encuentra en hardware/libhardware/include/hardware . Consulte sensores.h para obtener detalles adicionales.
Ciclo de lanzamiento
La implementación de HAL especifica qué versión de la interfaz HAL implementa configurando your_poll_device.common.version . Las versiones de interfaz HAL existentes se definen en sensores.h, y la funcionalidad está vinculada a esas versiones.
El marco de trabajo de Android actualmente es compatible con las versiones 1.0 y 1.3, pero la 1.0 pronto dejará de ser compatible. Esta documentación describe el comportamiento de la versión 1.3, a la que todos los dispositivos deben actualizarse. Para obtener detalles sobre cómo actualizar a 1.3, consulte Desactivación de la versión HAL .
controlador del núcleo
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 sensores que proporcionen los controladores, pero ellos son los que escriben la implementación de 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 brinda enfoques preferidos para escribirlos.
Concentrador de sensores
La pila de sensores de un dispositivo puede incluir opcionalmente un concentrador de sensores, útil para realizar algunos cálculos de bajo nivel a baja potencia 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 procesamiento por lotes de sensores, agregando FIFO de hardware para los eventos de sensores. Consulte Procesamiento por lotes para obtener más información.
Nota: Para desarrollar nuevas funciones de ContextHub que usen nuevos sensores o LED, también puede 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 separado y, a veces, se incluye en el mismo chip que el SoC. Las características importantes 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 computación genérica y aceleradores de hardware para permitir la computación de muy baja potencia para sensores de baja potencia.
Android no especifica cómo está diseñado el concentrador de sensores y cómo se comunica con los sensores y el SoC (bus I2C, bus SPI, etc.), pero debe apuntar a 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 desde el concentrador del sensor hasta el 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 sensores sin despertador).
Sensores
Esos son los chips MEM físicos que realizan las mediciones. En muchos casos, varios sensores físicos están presentes en el mismo chip. Por ejemplo, algunos chips incluyen un acelerómetro, un giroscopio y un magnetómetro. (Dichos chips a menudo se denominan chips de 9 ejes, ya que cada sensor proporciona datos sobre 3 ejes).
Algunos de esos chips también contienen algo de lógica para realizar cálculos habituales, como detección de movimiento, detección de pasos y fusión de sensores de 9 ejes.
Aunque los requisitos y recomendaciones de potencia y precisión de 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 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.