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 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 framework se encarga de vincular las distintas aplicaciones al HAL . El HAL en sí es de cliente único. Sin esta multiplexación a nivel de 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 al 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 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 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 Procesamiento por lotes para obtener más detalles.
- Cuando la última aplicación registrada en un sensor se da de baja de él, los marcos envían una solicitud al HAL para desactivar el sensor para que no se consuma energía 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 un ritmo más rápido, la primera aplicación también los recibirá a un ritmo más rápido.
- 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, imagine un sensor físico que pueda funcionar tanto en modo de “alta precisión” como de “bajo consumo”.
- En un dispositivo Android sólo se puede utilizar uno de esos dos modos, 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 satisficiera 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 garantiza que una aplicación no pueda modificar el comportamiento de los sensores, dañando otras aplicaciones.
Fusión de sensores
El marco 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 energéticamente como otras implementaciones. En la medida de lo posible, los fabricantes de dispositivos deberían 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 de sensores que les proporcionen una implementación.
La implementación predeterminada de fusión de sensores no se mantiene y podría provocar que los dispositivos que dependen de ella fallen en el CTS.
Bajo el capó
Esta sección se proporciona como información general para quienes mantienen el código 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 de sensores.
Carpeta IPC
Los proxies de Binder IPC 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 marco de Android. Consta de una interfaz HAL sensors.h y una implementación HAL a la que nos referimos como sensores.cpp.
La interfaz la definen los contribuyentes 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 la interfaz HAL existentes se definen en sensores.h, y la funcionalidad está vinculada a esas versiones.
El marco de trabajo de Android actualmente admite 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 Desuso 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 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 del kernel son responsabilidad de los fabricantes de hardware, y Android no proporciona enfoques preferidos para escribirlos.
Centro 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 suspendido. Por ejemplo, en esos chips se puede realizar el recuento de pasos o la fusión de sensores. También es un buen lugar para implementar el procesamiento por lotes de sensores, agregando FIFO de hardware para los eventos del sensor. Consulte Procesamiento por lotes para obtener más información.
Nota: Para desarrollar nuevas funciones de ContextHub que utilizan 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 centro de sensores depende de la arquitectura. A veces es un chip separado y otras 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 realizar procesamiento por lotes y consumir muy poca energía para permitir la implementación de sensores Android de bajo consumo. Algunos concentradores de sensores contienen un microcontrolador para cálculos genéricos y aceleradores de hardware para permitir cálculos de muy baja potencia para sensores de baja potencia.
Android no especifica la arquitectura del concentrador de sensores y cómo se comunica con los sensores y el SoC (bus I2C, bus SPI,…), 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 vayan desde el concentrador de sensores al SoC: una para interrupciones de activación (para sensores de activación) y la otra para interrupciones que no son de activación. (para sensores que no son despertadores).
Sensores
Esos son los chips MEM 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 denominarse chips de 9 ejes, ya que cada sensor proporciona datos en 3 ejes).
Algunos de esos chips también contienen cierta 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. Corresponde al fabricante del dispositivo derivar los requisitos para los sensores físicos.