Los teléfonos inteligentes contienen una serie de procesadores, cada uno optimizado para realizar diferentes tareas. Sin embargo, Android solo se ejecuta en un procesador: el procesador de aplicaciones (AP). El AP está ajustado para brindar un gran rendimiento en casos de uso con la pantalla encendida, como los juegos, pero consume demasiada energía para admitir funciones que requieren ráfagas de procesamiento breves y frecuentes todo el tiempo, incluso cuando la pantalla está apagada. Los procesadores más pequeños pueden manejar estas cargas de trabajo de manera más eficiente, completando sus tareas sin afectar notablemente la duración de la batería. Sin embargo, los entornos de software en estos procesadores de bajo consumo son más limitados y pueden variar mucho, lo que dificulta el desarrollo multiplataforma.
Context Hub Runtime Environment (CHRE) proporciona una plataforma común para ejecutar aplicaciones en un procesador de bajo consumo, con una API simple, estandarizada y fácil de integrar. CHRE facilita que los OEM de dispositivos y sus socios de confianza descarguen el procesamiento del AP, ahorren batería y mejoren varias áreas de la experiencia del usuario, y habilitan una clase de características contextuales siempre activas, especialmente aquellas que involucran la aplicación de la máquina. aprendiendo a sentir el ambiente.
Conceptos clave
CHRE es el entorno de software en el que pequeñas aplicaciones nativas, denominadas nanoaplicaciones , se ejecutan en un procesador de bajo consumo e interactúan con el sistema subyacente a través de la API común de CHRE. Para acelerar la implementación adecuada de las API de CHRE, se incluye una implementación de referencia multiplataforma de CHRE en AOSP. La implementación de referencia incluye código común y abstracciones para el hardware y software subyacente a través de una serie de capas de abstracción de plataforma (PAL). Las nanoaplicaciones casi siempre están vinculadas a una o más aplicaciones cliente que se ejecutan en Android, que interactúan con CHRE y nanoaplicaciones a través de las API del sistema ContextHubManager de acceso restringido.
En un alto nivel, se pueden establecer paralelismos entre la arquitectura de CHRE y Android en su conjunto. Sin embargo, hay algunas distinciones importantes:
- CHRE solo admite la ejecución de nanoaplicaciones desarrolladas en código nativo (C o C++); Java no es compatible.
- Debido a las limitaciones de recursos y de seguridad, CHRE no está abierto para que lo usen aplicaciones de Android de terceros arbitrarias. Solo las aplicaciones confiables del sistema pueden acceder a él.
También hay que hacer una distinción importante entre el concepto de CHRE y un concentrador de sensores. Si bien es común usar el mismo hardware para implementar el concentrador de sensores y CHRE, CHRE en sí no proporciona la funcionalidad de sensor requerida por Android Sensors HAL . CHRE está vinculado a Context Hub HAL y actúa como un cliente de un marco de sensor específico del dispositivo para recibir datos del sensor sin involucrar al AP.
Figura 1. Arquitectura del marco CHRE
Centro de contexto HAL
La capa de abstracción de hardware (HAL) de Context Hub es la interfaz entre el marco de trabajo de Android y la implementación de CHRE del dispositivo, definida en hardware/interfaces/contexthub . Context Hub HAL define las API a través de las cuales el marco de Android descubre los centros de contexto disponibles y sus nanoaplicaciones, interactúa con esas nanoaplicaciones a través del paso de mensajes y permite que se carguen y descarguen nanoaplicaciones. Una implementación de referencia de Context Hub HAL que funciona con la implementación de referencia de CHRE está disponible en system/chre/host .
En caso de conflicto entre esta documentación y la definición de HAL, la definición de HAL tiene prioridad.
Inicialización
Cuando se inicia Android, ContextHubService invoca la función HAL getHubs() para determinar si hay centros de contexto disponibles en el dispositivo. Esta es una llamada de bloqueo única, por lo que debe completarse rápidamente para evitar demoras en el inicio y debe devolver un resultado preciso, ya que no se pueden introducir nuevos centros de contexto después.
Carga y descarga de nanoaplicaciones
Un concentrador de contexto puede incluir un conjunto de nanoaplicaciones que se incluyen en la imagen del dispositivo y se cargan cuando se inicia CHRE. Estas se conocen como nanoaplicaciones precargadas y deben incluirse en la primera respuesta posible a queryApps() .
Context Hub HAL también admite la carga y descarga dinámica de nanoaplicaciones en tiempo de ejecución, a través de las loadNanoApp() y unloadNanoApp() . Las nanoaplicaciones se proporcionan a HAL en un formato binario específico para la implementación de hardware y software de CHRE del dispositivo.
Si la implementación para cargar una nanoaplicación implica escribirla en una memoria no volátil, como un almacenamiento flash conectado al procesador que ejecuta CHRE, entonces la implementación de CHRE siempre debe iniciarse con estas nanoaplicaciones dinámicas en estado deshabilitado. Esto significa que no se ejecuta ningún código de la nanoaplicación hasta que se recibe una solicitud enableNanoapp() a través de la HAL. Las nanoaplicaciones precargadas se pueden inicializar en el estado habilitado.
El centro de contexto se reinicia
Si bien no se espera que CHRE se reinicie durante el curso de la operación normal, puede ser necesario recuperarse de condiciones inesperadas, como un intento de acceder a una dirección de memoria no asignada. En estas situaciones, CHRE se reinicia independientemente de Android. HAL notifica a Android de esto a través del evento RESTARTED , que debe enviar solo después de que CHRE se haya reiniciado hasta el punto de que pueda aceptar nuevas solicitudes, como queryApps() .
Resumen del sistema CHRE
CHRE está diseñado en torno a una arquitectura impulsada por eventos, donde la unidad principal de computación es un evento pasado al punto de entrada de manejo de eventos de una nanoaplicación. Si bien el marco CHRE puede ser de subprocesos múltiples, una nanoaplicación determinada nunca se ejecuta desde varios subprocesos en paralelo. El marco de CHRE interactúa con una nanoaplicación determinada a través de uno de los tres puntos de entrada de nanoaplicaciones ( nanoappStart() , nanoappHandleEvent() y nanoappEnd() ) o a través de una devolución de llamada proporcionada en una llamada API de CHRE anterior, y las nanoaplicaciones interactúan con el marco de CHRE y el sistema subyacente a través de la API de CHRE. La API de CHRE proporciona un conjunto de funcionalidades básicas, así como instalaciones para acceder a señales contextuales, incluidos sensores, GNSS, Wi-Fi, WWAN y audio, y se puede ampliar con capacidades adicionales específicas del proveedor para uso de nanoaplicaciones específicas del proveedor. .
sistema de construcción
Si bien Context Hub HAL y otros componentes necesarios del lado de AP se crean junto con Android, el código que se ejecuta dentro de CHRE puede tener requisitos que lo hacen incompatible con el sistema de compilación de Android, como la necesidad de una cadena de herramientas especializada. Por lo tanto, el proyecto CHRE en AOSP proporciona un sistema de compilación simplificado basado en GNU Make para compilar nanoaplicaciones y, opcionalmente, el marco CHRE en bibliotecas que se pueden integrar con el sistema. Los fabricantes de dispositivos que agregan soporte para CHRE deben integrar el soporte del sistema de compilación para sus dispositivos de destino en AOSP.
La API de CHRE está escrita en el estándar de lenguaje C99 y la implementación de referencia utiliza un subconjunto restringido de C++11 adecuado para aplicaciones con recursos limitados.
API de CHRE
La API de CHRE es una colección de archivos de encabezado C que definen la interfaz de software entre una nanoaplicación y el sistema. Está diseñado para hacer que el código de las nanoaplicaciones sea compatible en todos los dispositivos compatibles con CHRE, lo que significa que no es necesario modificar el código fuente de una nanoaplicación para admitir un nuevo tipo de dispositivo, aunque es posible que deba volver a compilarse específicamente para el procesador del dispositivo de destino. conjunto de instrucciones o interfaz binaria de aplicación (ABI). La arquitectura de CHRE y el diseño de la API también garantizan que las nanoaplicaciones sean compatibles binariamente en diferentes versiones de la API de CHRE, lo que significa que una nanoaplicación no necesita volver a compilarse para ejecutarse en un sistema que implementa una versión diferente de la API de CHRE en comparación con la API de destino contra la que se compila la nanoaplicación. En otras palabras, si un binario de nanoaplicación se ejecuta en un dispositivo compatible con CHRE API v1.3 y ese dispositivo se actualiza para admitir CHRE API v1.4, el mismo binario de nanoaplicación continúa funcionando. De manera similar, la nanoaplicación puede ejecutarse en CHRE API v1.2 y puede determinar en tiempo de ejecución si requiere funcionalidad de API v1.3 para lograr su funcionalidad, o si puede operar, potencialmente con una degradación elegante de las funciones.
Las nuevas versiones de la API de CHRE se lanzan junto con Android; sin embargo, dado que la implementación de CHRE es parte de la implementación del proveedor , la versión de la API de CHRE admitida en un dispositivo no está necesariamente vinculada a una versión de Android.
Resumen de la versión
Al igual que el esquema de control de versiones HIDL de Android , la API de CHRE sigue el control de versiones semántico . La versión principal indica compatibilidad binaria, mientras que la versión secundaria se incrementa cuando se introducen características compatibles con versiones anteriores. La API de CHRE incluye anotaciones de código fuente para identificar qué versión introdujo una función o parámetro, por ejemplo, @since v1.1 .
La implementación de CHRE también expone una versión de parche específica de la plataforma a través chreGetVersion() , que indica cuándo se realizan correcciones de errores o actualizaciones menores en la implementación.
Versión 1.0 (Android 7)
Incluye compatibilidad con sensores y funciones básicas de nanoaplicaciones, como eventos y temporizadores.
Versión 1.1 (Android 8)
Introduce capacidades de ubicación a través de ubicación GNSS y mediciones sin procesar, escaneo de Wi-Fi e información de red celular, junto con mejoras generales para permitir la comunicación de nanoaplicación a nanoaplicación y otras mejoras.
Versión 1.2 (Android 9)
Agrega soporte para datos de un micrófono de baja potencia, rango de Wi-Fi RTT, notificaciones de activación/reposo de AP y otras mejoras.
Versión 1.3 (Android 10)
Mejora las capacidades relacionadas con los datos de calibración del sensor, agrega soporte para descargar datos del sensor por lotes a pedido, define el tipo de sensor de detección de pasos y amplía los eventos de ubicación GNSS con campos de precisión adicionales.
Versión 1.4 (Android 11)
Agrega soporte para información de celdas 5G, volcado de depuración de nanoaplicaciones y otras mejoras.
Funciones obligatorias del sistema
Si bien las fuentes de señales contextuales, como los sensores, se clasifican en áreas de funciones opcionales, se requieren algunas funciones básicas en todas las implementaciones de CHRE. Esto incluye las API del sistema central, como las que se utilizan para configurar temporizadores, enviar y recibir mensajes a clientes en el procesador de aplicaciones, registro y otros. Para obtener detalles completos, consulte los encabezados de la API .
Además de las funciones básicas del sistema codificadas en la API de CHRE, también hay funciones obligatorias a nivel de sistema de CHRE especificadas en el nivel HAL de Context Hub. La más importante de ellas es la capacidad de cargar y descargar nanoaplicaciones dinámicamente.
Biblioteca estándar C/C++
Para minimizar el uso de la memoria y la complejidad del sistema, las implementaciones de CHRE deben admitir solo un subconjunto de las bibliotecas C y C++ estándar y las características del lenguaje que requieren compatibilidad con el tiempo de ejecución. Siguiendo estos principios, algunas características se excluyen explícitamente debido a su memoria y/o amplias dependencias a nivel del sistema operativo, y otras porque son reemplazadas por API específicas de CHRE más adecuadas. Si bien no pretende ser una lista exhaustiva, las siguientes capacidades no están destinadas a estar disponibles para las nanoaplicaciones:
- Excepciones de C++ e información de tipo de tiempo de ejecución (RTTI)
- Compatibilidad con subprocesos múltiples de la biblioteca estándar, incluidos los encabezados C++11
<thread>,<mutex>,<atomic>,<future> - Bibliotecas de entrada/salida estándar C y C++
- Biblioteca de plantillas estándar de C++ (STL)
- Biblioteca de expresiones regulares estándar de C++
- Asignación de memoria dinámica a través de funciones estándar (por ejemplo,
malloc,calloc,realloc,free,operator new) y otras funciones de biblioteca estándar que utilizan inherentemente la asignación dinámica, comostd::unique_ptr - Localización y compatibilidad con caracteres Unicode
- Bibliotecas de fecha y hora
- Funciones que modifican el flujo normal del programa, incluidas
<setjmp.h>,<signal.h>,abort,std::terminate - Acceso al entorno del host, incluidos
system,getenv - POSIX y otras bibliotecas no incluidas en los estándares de lenguaje C99 o C++11
En muchos casos, la funcionalidad equivalente está disponible en las funciones API de CHRE y/o bibliotecas de utilidades. Por ejemplo, chreLog se puede usar para el registro de depuración dirigido al sistema logcat de Android, donde un programa más tradicional podría usar printf o std::cout .
Por el contrario, se requiere alguna funcionalidad de biblioteca estándar. Depende de la implementación de la plataforma exponerlos a través de bibliotecas estáticas para incluirlos en un binario de nanoaplicación, o mediante un enlace dinámico entre la nanoaplicación y el sistema. Esto incluye, pero no se limita a:
- Utilidades de cadenas/matrices:
memcmp,memcpy,memmove,memset,strlen Biblioteca matemática: funciones de punto flotante de precisión simple de uso común:
- Operaciones básicas:
ceilf,fabsf,floorf,fmaxf,fminf,fmodf,roundf,lroundf,remainderf - Funciones exponenciales/de potencia:
expf,log2f,powf,sqrtf - Funciones trigonométricas/hiperbólicas:
sinf,cosf,tanf,asinf,acosf,atan2f,tanhf
- Operaciones básicas:
Si bien algunas plataformas subyacentes admiten funciones adicionales, una nanoaplicación no se considera portátil en las implementaciones de CHRE a menos que restrinja sus dependencias externas a las funciones de la API de CHRE y las funciones de biblioteca estándar aprobadas.
Características opcionales
Para promover el hardware y el software, la API de CHRE se divide en áreas de funciones, que se consideran opcionales desde la perspectiva de la API. Si bien es posible que estas características no sean necesarias para admitir una implementación de CHRE compatible, es posible que sean necesarias para admitir una nanoaplicación en particular. Incluso si una plataforma no admite un conjunto determinado de API, las nanoaplicaciones que hacen referencia a esas funciones deben poder compilarse y cargarse.
Sensores
La API de CHRE brinda la capacidad de solicitar datos de sensores que incluyen acelerómetro, giroscopio, magnetómetro, sensor de luz ambiental y proximidad. Estas API están destinadas a proporcionar un conjunto de funciones similar a las API de los sensores de Android, incluida la compatibilidad con el procesamiento por lotes de muestras de sensores para reducir el consumo de energía. El procesamiento de datos de sensores dentro de CHRE permite un procesamiento de señales de movimiento con mucha menos potencia y menor latencia en comparación con la ejecución en el AP.
GNSS
CHRE proporciona API para solicitar datos de ubicación de un sistema global de navegación por satélite (GNSS), incluidos GPS y otras constelaciones de satélites. Esto incluye solicitudes de correcciones de posición periódicas, así como datos de medición sin procesar, aunque ambas son capacidades independientes. Como CHRE tiene un enlace directo al subsistema GNSS, la potencia se reduce en comparación con las solicitudes GNSS basadas en AP, porque el AP puede permanecer inactivo durante todo el ciclo de vida de una sesión de ubicación.
Wifi
CHRE brinda la capacidad de interactuar con el chip Wi-Fi, principalmente con fines de ubicación. Si bien GNSS funciona bien para ubicaciones al aire libre, los resultados de los escaneos de Wi-Fi pueden proporcionar información de ubicación precisa en interiores y en áreas desarrolladas. Además de evitar el costo de activar el AP para un escaneo, CHRE puede escuchar los resultados de los escaneos de Wi-Fi realizados por el firmware de Wi-Fi con fines de conectividad, que normalmente no se envían al AP por motivos de energía. Aprovechar los escaneos de conectividad para fines contextuales ayuda a reducir la cantidad total de escaneos de Wi-Fi realizados, lo que ahorra energía.
Se agregó soporte para Wi-Fi en CHRE API v1.1, incluida la capacidad de monitorear los resultados del escaneo y activar escaneos a pedido. Estas capacidades se ampliaron en v1.2 con la capacidad de realizar mediciones de tiempo de ida y vuelta (RTT) en puntos de acceso compatibles con la función, lo que permite una determinación precisa de la posición relativa.
WWAN
La API de CHRE brinda la capacidad de recuperar información de identificación de celda para la celda de servicio y sus vecinos, que normalmente se usa para fines de ubicación de grano grueso.
Audio
CHRE puede procesar lotes de datos de audio desde un micrófono de baja potencia, que generalmente aprovecha el hardware utilizado para implementar SoundTrigger HAL. El procesamiento de datos de audio en CHRE puede permitir que se fusionen con otros datos, como sensores de movimiento.
Implementación de referencia
El código de referencia para el marco CHRE está incluido en AOSP en el proyecto system/chre , implementado en C++11. Si bien no es estrictamente necesario, se recomienda que todas las implementaciones de CHRE se basen en este código base para ayudar a garantizar la coherencia y acelerar la adopción de nuevas capacidades. Este código se puede ver como un análogo del marco de Android central en el sentido de que es una implementación de código abierto de las API que usan las aplicaciones, que sirve como referencia y estándar para la compatibilidad. Si bien se puede personalizar y ampliar con capacidades específicas del proveedor, la recomendación es mantener el código común lo más cerca posible de la referencia. Al igual que las HAL de Android, la implementación de referencia de CHRE utiliza varias abstracciones de plataforma para permitir que se adapte a cualquier dispositivo que cumpla con los requisitos mínimos.
Para obtener detalles técnicos y una guía de portabilidad, consulte el LÉAME incluido en el proyecto system/chre .