Los smartphones cuentan con varios procesadores, cada uno optimizado para funcionar diferentes tareas. Sin embargo, Android solo se ejecuta en un procesador: las aplicaciones (AP). El AP está ajustado para ofrecer un rendimiento excelente de la pantalla encendida. casos de uso como los videojuegos, pero se necesita demasiada energía para admitir funciones que requieren picos de actividad de procesamiento cortos y frecuentes todo el tiempo, incluso cuando la pantalla está desactivada. Los procesadores más pequeños pueden controlar estas cargas de trabajo de forma más eficiente completar sus tareas sin afectar de forma notoria la duración de la batería. Sin embargo, el entornos de software en estos procesadores de bajo consumo son más limitados y pueden varían mucho, lo que dificulta el desarrollo multiplataforma.
El entorno de ejecución del centro de contexto (CHRE) proporciona una plataforma común para ejecutar apps en un procesador de bajo consumo, con una interfaz simple, API compatible con incorporación. CHRE facilita el trabajo a los OEM de dispositivos y sus clientes socios para transferir el procesamiento del AP, ahorrar batería y mejorar varios de la experiencia del usuario y habilitar una clase de interacción funciones adaptadas al contexto, especialmente aquellas relacionadas con la aplicación de del aprendizaje automático a la detección de ambientes.
Conceptos clave
CHRE es el entorno de software en el que las aplicaciones nativas pequeñas, denominadas
nanoapps, se ejecutan en un procesador de bajo consumo y también interactúan con
sistema a través de la API de CHRE común. Para acelerar la implementación adecuada del
CHRE, una implementación de referencia multiplataforma de CHRE se incluye en
AOSP. La implementación de referencia incluye código y abstracciones comunes en el
de hardware y software subyacentes a través de una serie de capas de abstracción de plataformas
(PAL). Las nanoapps casi siempre están vinculadas a una o más apps cliente que se ejecutan en
Android, que interactúan con CHRE y nanoapps mediante el acceso restringido
ContextHubManager
y las APIs del sistema.
En un nivel alto, se pueden trazar paralelos entre la arquitectura de CHRE y Android en su totalidad Sin embargo, existen algunas diferencias importantes:
- CHRE admite la ejecución únicamente de nanoapps desarrolladas en código nativo (C o C++); No se admite Java.
- Debido a restricciones de recursos y limitaciones de seguridad, CHRE no está abierto. para que la usen las apps arbitrarias de Android de terceros. Solo las apps de confianza del sistema pueden accedan a ellos.
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 centro de sensores y CHRE; el CHRE en sí no proporciona las capacidades requeridos por los sensores de Android HAL. CHRE está vinculado a la HAL del centro de contexto, que actúa como cliente de un sensor específico del dispositivo para recibir datos de sensores sin involucrar al AP.
Figura 1: Arquitectura de marco de trabajo de CHRE
HAL del centro de contexto
La capa de abstracción de hardware (HAL) del centro de contexto es la interfaz entre las
el framework de Android y la implementación de CHRE del dispositivo, definidos en
hardware/interfaces/contexthub
La HAL del centro de contexto define las APIs a través de las cuales el framework de Android
descubre centros de contexto disponibles y sus nanoapps, interactúa con esos
a través del envío de mensajes, y permite que las nanoapps se carguen y
sin cargar. Una implementación de referencia de la HAL del centro de contexto que funciona con la
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, el La definición de HAL tiene prioridad.
Inicialización
Cuando se inicia Android, el
ContextHubService
invoca la función HAL getHubs() para determinar si se puede
disponibles en el dispositivo. Esta es una llamada de bloqueo, así que debe completarse
con rapidez para evitar retrasar el inicio y debe devolver un resultado exacto, ya que
no se pueden agregar centros de contexto más adelante.
Cómo cargar y descargar nanoapps
Un concentrador de contexto puede tener
un conjunto de nanoapps que se incluyen
y se cargan cuando se inicia CHRE. Se conocen como nanoapps precargadas,
y deben incluirse en la primera respuesta posible a queryApps().
La HAL de Context Hub también admite la carga y la descarga dinámica de nanoapps en
entorno de ejecución, a través de las funciones loadNanoApp() y unloadNanoApp(). Nanoapps
se proporcionan a la HAL en un formato binario específico para el hardware de CHRE.
implementación de software del dispositivo.
Si la implementación para cargar una nanoapp implica escribirla en un formato
como un almacenamiento flash conectado al procesador que ejecuta CHRE, el
La implementación de CHRE siempre debe iniciarse con estas nanoapps dinámicas en el
inhabilitado. Esto significa que el código de la nanoapp no se ejecuta hasta que
Se recibe una solicitud de enableNanoapp() a través de la HAL. Las nanoapps precargadas
se inicializa en el estado habilitado.
Reinicios del concentrador de contexto
Si bien no se espera que CHRE se reinicie durante el curso de su funcionamiento normal,
puede ser necesario para recuperarse de condiciones inesperadas, como un intento de
acceder a una dirección de memoria sin asignar. En estos casos, CHRE reinicia
independientemente de Android. La HAL notifica a Android de esto a través del
RESTARTED, que se debe enviar solo después de que CHRE se haya reinicializado a
el punto en que puede aceptar solicitudes nuevas, como queryApps().
Descripción general del sistema CHRE
CHRE se diseñó en torno a una arquitectura basada en eventos, donde la unidad principal de
procesamiento es un evento que se pasa al punto de entrada de control de eventos de una nanoapp. Mientras que
el framework de CHRE puede ser multisubproceso, una nanoapp determinada nunca se ejecuta desde
varios subprocesos en paralelo. El framework de CHRE interactúa con una nanoapp determinada.
a través de uno de los tres puntos de entrada de nanoapp (nanoappStart(),
nanoappHandleEvent() y nanoappEnd()) o mediante una devolución de llamada proporcionada en una
llamada a la API de CHRE anterior, y las nanoapps interactúan con el framework de CHRE y el
del sistema subyacente con la API de CHRE. La API de CHRE brinda un conjunto de
así como también instalaciones para acceder a señales contextuales, como
GNSS, Wi-Fi, WWAN y audio, y se puede extender con
capacidades específicas de los proveedores para que las usen las nanoapps específicas de estos.
Sistema de compilación
Mientras que la HAL del Centro de contexto y otros componentes necesarios del AP se compilan junto con Android, el código que se ejecuta en CHRE puede tener requisitos que incompatibles con el sistema de compilación de Android, como la necesidad de un software de la cadena de herramientas. Por lo tanto, el proyecto CHRE en AOSP proporciona una compilación simplificada basado en GNU Make para compilar nanoapps y, opcionalmente, el archivo CHRE en bibliotecas que se pueden integrar con el sistema. Dispositivo los fabricantes que agregan compatibilidad con CHRE deben integrar la compatibilidad del sistema de compilación para sus dispositivos de destino en AOSP.
La API de CHRE se escribe según el estándar de lenguaje C99, y la referencia implementación usa un subconjunto restringido de C++11 adecuado para recursos limitados de Google Chat.
API de CHRE
La API de CHRE es una colección de archivos de encabezado C que define el software entre una nanoapp y el sistema. Se diseñó para crear nanoapps código compatible en todos los dispositivos que admiten CHRE, lo que significa que el no es necesario modificar el código fuente de una nanoapp para admitir un dispositivo nuevo. aunque podría tener que volver a compilarse específicamente para la configuración del dispositivo conjunto de instrucciones del procesador o la interfaz binaria de la aplicación (ABI). CHRE La arquitectura y el diseño de las APIs también garantizan que las nanoapps sean compatibles con objetos binarios. en diferentes versiones de la API de CHRE, lo que significa que una nanoapp no se deben volver a compilar para que se ejecuten en un sistema que implementa una versión diferente del la API de CHRE en comparación con la API de destino con la que se compila la nanoapp. En otras palabras, si un objeto binario de nanoapp se ejecuta en un dispositivo compatible con la API de CHRE v1.3, y el dispositivo se actualizará para ser compatible con la API de CHRE v1.4, la misma binario sigue funcionando. Del mismo modo, la nanoapp puede ejecutarse en la API de CHRE v1.2, y puede determinar en el tiempo de ejecución si requiere capacidades de la API v1.3 para lograr su uso o si puede operar, potencialmente, con la degradación de los atributos.
Las nuevas versiones de la API de CHRE se lanzan junto con Android; sin embargo, como CHRE, implementación es parte del implementación de proveedores, 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
Como 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 es
se incrementan cuando se introducen
funciones retrocompatibles. La API de CHRE
Incluye anotaciones de código fuente para identificar qué versión presentó una función
o parámetro, por ejemplo, @since v1.1.
La implementación de CHRE también expone una versión del parche específica de la plataforma a través de
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 principales de nanoapp, como eventos y temporizadores.
Versión 1.1 (Android 8)
Presenta capacidades de ubicación a través de la ubicación del GNSS y las mediciones sin procesar. Búsqueda de Wi-Fi e información de redes móviles, además de mejoras generales para habilitar la comunicación entre nanoapp y nanoapp, entre otras mejoras.
Versión 1.2 (Android 9)
Agrega compatibilidad con datos de un micrófono de baja potencia, rango de Wi-Fi RTT y AP. notificaciones de activación y sueño, y otras mejoras.
Versión 1.3 (Android 10)
Mejora las capacidades relacionadas con los datos de calibración del sensor y agrega compatibilidad limpiar los datos de sensores por lotes a pedido, define el tipo de sensor de detección de pasos y extiende los eventos de ubicación de GNSS con campos de precisión adicionales.
Versión 1.4 (Android 11)
Se agregó compatibilidad con la información de celdas 5G, el volcado de depuración de nanoapp y otros. mejoras continuas.
Atributos obligatorios del sistema
Si bien las fuentes de señales contextuales, como los sensores, se categorizan en áreas de características específicas, se requieren algunas funciones principales en todo CHRE de Google Cloud. Esto incluye las APIs principales del sistema, como las que se usan para establecer temporizadores, el envío y la recepción de mensajes a clientes en el procesador de aplicaciones, Logging, entre otros. Para obtener más información, consulta la Encabezados de la API.
Además de las funciones principales del sistema codificadas en la API de CHRE, también hay atributos obligatorios a nivel del sistema de CHRE especificados en el nivel de HAL del centro de contexto. El lo más importante es la capacidad de cargar y descargar dinámicamente nanoapps.
Biblioteca C/C++ estándar
Para minimizar el uso de memoria y la complejidad del sistema, las implementaciones de CHRE son necesaria para admitir solo un subconjunto de las bibliotecas C y C++ estándar, y de lenguaje extensos que requieren compatibilidad con el entorno de ejecución. De acuerdo con estos principios, algunas las funciones se excluyen explícitamente debido a su memoria y sus capacidades extensas las dependencias y otros porque son suplantados por APIs específicas de CHRE. Si bien no debe ser una lista exhaustiva, los siguientes no están disponibles para nanoapps:
- Excepciones de C++ e información de tipo de entorno de ejecución (RTTI)
- Compatibilidad con varios subprocesos de biblioteca estándar, incluidos encabezados de C++11.
<thread>,<mutex>,<atomic>y<future> - Bibliotecas de entrada y salida estándar de C y C++
- Biblioteca de plantillas C++ estándar (STL)
- Biblioteca de expresiones regulares estándar de C++
- Asignación dinámica de memoria mediante funciones estándar (por ejemplo,
malloc,calloc,realloc,free,operator new) y otro estándar. funciones de biblioteca que usan de forma inherente 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 de programa normal, como
<setjmp.h><signal.h>,abortystd::terminate - Accede al entorno del host, incluidos
systemygetenv - POSIX y otras bibliotecas no incluidas en los lenguajes C99 o C++11 estándares
En muchos casos, las funciones de la API de CHRE ofrecen capacidades equivalentes.
y bibliotecas de utilidades. Por ejemplo, se puede usar chreLog para el registro de depuración.
orientado al sistema Android logcat, donde un programa más tradicional podría
usa printf o std::cout.
Por el contrario, se requieren algunas capacidades de biblioteca estándar. Depende de la implementación de la plataforma para exponerlos a través de bibliotecas estáticas para su inclusión en un objeto binario de nanoapp o mediante la vinculación dinámica entre la nanoapp y el sistema. Esta incluye, entre otros:
- Utilidades de cadenas y array:
memcmp,memcpy,memmove,memset,strlen Biblioteca de matemáticas: Funciones de punto flotante de precisión simple de uso general:
- Operaciones básicas:
ceilf,fabsf,floorf,fmaxf,fminf,fmodfyroundf,lroundf,remainderf - Funciones exponenciales y de potencia:
expf,log2f,powf,sqrtf - Funciones hiperbólicas y trigonométricas:
sinf,cosf,tanf,asinf,acosf,atan2fytanhf
- Operaciones básicas:
Si bien algunas plataformas subyacentes admiten capacidades adicionales, una nanoapp no se considera portátil en todas las implementaciones de CHRE, a menos que restrinja su Dependencias externas a las funciones de la API de CHRE y a la biblioteca estándar aprobada funciones.
Funciones opcionales
Para promocionar 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 estas funciones pueden no ser necesarios para admitir una implementación de CHRE compatible, pueden necesarias para admitir una nanoapp en particular. Incluso si una plataforma no admite conjunto determinado de APIs, las nanoapps que hagan referencia a esas funciones deben ser capaces de y la carga.
Sensores
La API de CHRE permite solicitar datos de sensores, como acelerómetro, giroscopio, magnetómetro, sensor de luz ambiente y proximidad. Estas APIs están diseñadas para proporcionar un conjunto de funciones similares al de los sensores de Android APIs, incluida la compatibilidad con el procesamiento por lotes de muestras de sensores para reducir el consumo de energía. El procesamiento de los datos de sensores dentro del sistema CHRE permite reducir el consumo de energía y la latencia. de las señales de movimiento en comparación con la ejecución en el PA.
GNSS
CHRE proporciona APIs para solicitar datos de ubicación a partir de una navegación global. satelital (GNSS), incluido el GPS y otras constelaciones de satélites. Esta incluye solicitudes de correcciones periódicas de posición, así como datos de medición sin procesar, aunque ambas son capacidades independientes. Como CHRE tiene un vínculo directo al GNSS, se reduce el consumo de energía en comparación con las solicitudes de GNSS basadas en AP, ya que el AP pueden permanecer dormidas durante todo el ciclo de vida de una sesión de ubicación.
Wi-Fi
CHRE brinda la capacidad de interactuar con el chip Wi-Fi, principalmente para de ubicación. Si bien el GNSS funciona bien en exteriores, los resultados de Los escaneos de Wi-Fi pueden proporcionar información de ubicación precisa en interiores y en centros de en esas áreas. Además de evitar el costo de activar el PA para un escaneo, CHRE puede escuchar los resultados de las búsquedas de Wi-Fi realizadas por la red Wi-Fi con fines de conectividad, que por lo general no se entregan al PA por motivos de energía. Aprovechar los análisis de conectividad con fines contextuales para reducir la cantidad total de búsquedas de Wi-Fi realizadas, lo que ahorra energía.
En la versión 1.1 de la API de CHRE, se agregó compatibilidad con Wi-Fi, incluida la capacidad de supervisar y activar análisis a pedido. Estas capacidades se ampliaron v1.2 con la capacidad de realizar Tiempo de ida y vuelta (RTT) en comparación con los puntos de acceso que admiten la función, lo que permite una determinación precisa de la posición relativa.
WWAN
La API de CHRE permite recuperar información de identificación de celdas de la celda de servicio y sus vecinas, lo que generalmente se usa para para fines de ubicación poco detallados.
Audio
CHRE puede procesar lotes de datos de audio desde un micrófono de bajo consumo, lo que por lo general, aprovecha el hardware que se usa para implementar la HAL de SoundTrigger. Procesando Los datos de audio en CHRE pueden permitir que se fusionen con otros datos, como el sensores.
Implementación de referencia
El código de referencia para el marco de trabajo CHRE se incluye en el AOSP en el system/chre.
implementado en C++11. Si bien no es estrictamente obligatorio, se recomienda
que todas las implementaciones de CHRE se basen en esta base de código para ayudar a garantizar
y acelera la adopción de nuevas capacidades. Este código se puede ver
como análogo al framework principal de Android, ya que es un modelo de código abierto
implementación de APIs que usan las apps, que funciona como modelo de referencia y estándar
para comprobar la compatibilidad. Si bien puede personalizarse y ampliarse con recursos
capacidades, se recomienda mantener el código común lo más cerca del
referencia como sea posible. Al igual que las HAL de Android, la referencia de CHRE
usa diversas abstracciones de la plataforma para permitir su adaptación
con cualquier dispositivo que cumpla
con los requisitos mínimos.
Para obtener detalles técnicos y una guía de portabilidad, consulta la
README
incluido en el proyecto system/chre.