En la siguiente figura, se representa la pila de sensores de Android. Cada componente se comunica solo con los componentes justo encima y debajo de él, aunque algunos los sensores pueden evitar el concentrador de sensores cuando está presente. Flujos de control desde la aplicaciones hasta los sensores, y los datos fluyen desde los sensores hasta los sensores 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 de sensores (kit de desarrollo de software). 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 muestreo preferido y sus requisitos de latencia.
- Por ejemplo, una aplicación puede registrarse en el acelerómetro predeterminado, solicitar eventos a 100 Hz y permitir que los eventos se informen con una duración de latencia.
- La aplicación recibirá eventos del acelerómetro a una velocidad de, al menos 100 Hz y puede retrasarse hasta 1 segundo.
Si deseas obtener más información sobre el SDK, consulta la documentación para desarrolladores.
Framework
El framework se encarga de vincular las distintas aplicaciones a la HAL. La HAL en sí es de un solo cliente. Si no se produce esta multiplexación en a nivel del framework, solo una aplicación podía acceder a cada sensor en cualquier momento dado.
- Cuando una primera aplicación se registra en un sensor, el framework envía una solicitud al HAL para activar el sensor.
- Cuando aplicaciones adicionales se registran en el mismo sensor, el framework tarda
en cuenta los requisitos de cada aplicación y envía la versión
parámetros a la HAL.
- La frecuencia de muestreo será la máxima de las frecuencias de muestreo solicitadas, es decir, las aplicaciones recibirán eventos con una frecuencia mayor que la que solicitado.
- La latencia máxima de los informes será la mínima de las solicitadas. Si una aplicación solicita uno con una latencia de informe máxima de 0, todas las aplicaciones recibirán la eventos de este sensor en modo continuo, incluso si algunos solicitaron el sensor con una latencia de informe máxima que no sea cero. Consulta Agrupación en lotes para obtener más detalles.
- Cuando se cancela el registro de la última aplicación registrada en un sensor, el envían una solicitud a la HAL para desactivar el sensor de modo que no se consuma la energía se consumen innecesariamente.
Impacto de la multiplexación
La necesidad de una capa de multiplexación en el framework explica algunos aspectos decisiones.
- Cuando una aplicación solicita una frecuencia de muestreo específica, no hay garantiza que los eventos no lleguen a un ritmo más rápido. Si se agrega otra aplicación el mismo sensor más rápido, la primera aplicación también y recibirlos rápidamente.
- La misma falta de garantía se aplica a la latencia de informe máxima solicitada: las aplicaciones podrían recibir eventos con mucha menos latencia de la solicitada.
- Además de la frecuencia de muestreo y la latencia máxima de los informes, las aplicaciones no pueden
configurar los parámetros del sensor.
- Por ejemplo, imagine un sensor físico que puede funcionar tanto en “precisión” y “baja energía”.
- Solo se puede usar uno de esos dos modos en un dispositivo Android porque de lo contrario, una aplicación podría solicitar el modo de Precisión alta y otro un modo de bajo consumo; no habría forma de que el framework satisfaga ambas aplicaciones. El framework siempre debe ser capaz de satisfacer a todos sus clientes, así que esta no es una opción.
- No hay un mecanismo para enviar datos desde las aplicaciones hasta los sensores o sus conductores. Esto garantiza que una aplicación no pueda modificar el comportamiento de la sensores, romper otras aplicaciones.
Fusión de sensores
El framework de Android proporciona una implementación predeterminada para algunas aplicaciones compuestas sensores. Cuando hay un giroscopio, un acelerómetro y un magnetómetro en un dispositivo, pero no hay sensores de vector de rotación, gravedad ni aceleración lineal, el framework implementa esos sensores para que las aplicaciones aún puedan usarlos.
La implementación predeterminada no tiene acceso a todos los datos que otros las implementaciones tienen acceso y deben ejecutarse en el SoC, por lo que no es tan ni tan eficientes en términos de energía como otras implementaciones. Tanto como posible, los fabricantes de dispositivos deberían definir sus propios sensores fusionados (rotación de la gravedad y la aceleración lineal del vector, así como los sensores compuestos más nuevos, como el vector de rotación del juego) en lugar de depender de esta implementación predeterminada. Los fabricantes de dispositivos 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 hacer que los dispositivos que dependen de él fallen en el CTS.
Bajo la superficie
Esta sección se proporciona como información general para quienes mantienen la Código del framework del Proyecto de código abierto de Android (AOSP). No es relevante para de hardware y 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 framework
equivalente al paquete android.hardware. El framework nativo llama a los proxies IPC de Binder para obtener acceso a
servicios específicos de sensores.
IPC de Binder
Los proxies 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 de sensores (HAL) es la interfaz entre las controladores de hardware y el framework de Android. Consiste en una interfaz HAL sensores.h y una implementación de HAL a la que nos referimos como sensores.cpp
Los colaboradores de Android y AOSP definen la interfaz, la proporciona el fabricante del dispositivo.
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 debe tener.
implementa mediante la configuración de your_poll_device.common.version. La HAL existente
de interfaz de usuario se definen en sensores.h, y la funcionalidad está vinculada a aquellas
versiones.
En la actualidad, el framework de Android admite las versiones 1.0 y 1.3, pero la 1.0 pronto dejarán de ser compatibles. En esta documentación, se 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, consulta Baja de la versión de HAL.
Controlador Kernel
Los controladores del sensor interactúan con los dispositivos físicos. En algunos casos, la 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 el pero 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 fabricantes de hardware, y Android no brinda enfoques preferidos para escribirlos.
Concentrador de sensores
La pila de sensores de un dispositivo puede incluir, de manera opcional, un concentrador de sensores, que sirve para realizar cálculos de bajo nivel con poca potencia, mientras que el SoC puede estar modo de suspensión. Por ejemplo, el recuento de pasos o la fusión de sensores pueden realizarse esos chips. También es un buen lugar para implementar el agrupamiento de sensores en lotes, los FIFO de hardware para los eventos de sensores. Consulta Agrupación en lotes para obtener más información.
Nota: Para desarrollar nuevas funciones de ContextHub que usar nuevos sensores o LEDs, también puedes usar El Neonkey SensorHub conectado a un Placa de desarrollo Hikey o Hikey960.
La forma en que se materializa el concentrador de sensores depende de la arquitectura. En ocasiones, en un chip independiente y, a veces, se incluyen en el mismo chip que el SoC. Importantes características del concentrador de sensores es que debe contener suficiente memoria para agrupar en lotes y consumir muy poca energía para permitir la implementación de la baja potencia los sensores Android. Algunos concentradores de sensores contienen un microcontrolador para y aceleradores de hardware para permitir un cálculo de muy baja energía para sensores de bajo consumo.
Cómo está arquitectura el concentrador de sensores y cómo se comunica con los sensores Android no especifica el SoC (bus I2C, bus SPI, etc.), pero debería apuntar para minimizar el uso general de energía.
Una opción que parece tener un impacto significativo en la implementación es tener dos líneas de interrupción que vayan del concentrador del sensor al SoC: uno para interrupciones que se producen cuando se despierta (para sensores de activación) y otro para cuando no lo son interrupciones (para sensores que no son de activación).
Sensores
Esos son los chips físicos de MEM 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. (Dichos chips suelen llamados chips de 9 ejes, ya que cada sensor proporciona datos en más de 3 ejes).
Algunos de esos chips también contienen algo de lógica para realizar cálculos habituales, como como detección de movimiento, detección de pasos y fusión de sensores de 9 ejes.
Si bien los requisitos y recomendaciones de potencia y precisión del CDD se orientan a en lugar de los sensores físicos, esos requisitos afectan la variedad de sensores físicos. Por ejemplo, el requisito de precisión del juego el vector de rotación tiene implicaciones en la exactitud requerida para la giroscopio. Depende del fabricante del dispositivo derivar los requisitos para con sensores físicos.