Los smartphones contienen varios 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á optimizado para ofrecer un excelente rendimiento en casos de uso con la pantalla encendida, como los juegos, pero consume demasiada energía para admitir funciones que requieren ráfagas frecuentes y cortas de procesamiento todo el tiempo, incluso cuando la pantalla está apagada. Los procesadores más pequeños pueden controlar estas cargas de trabajo de manera más eficiente y completar 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.
El entorno de tiempo de ejecución del centro de contexto (CHRE) proporciona una plataforma común para ejecutar apps en un procesador de bajo consumo, con una API simple, estandarizada y compatible con dispositivos integrados. CHRE facilita que los OEMs de dispositivos y sus socios de confianza descarguen el procesamiento del AP para ahorrar batería y mejorar varias áreas de la experiencia del usuario, y habilitar una clase de funciones siempre activas y contextuales, en especial aquellas que implican la aplicación del aprendizaje automático a la detección ambiental.
Conceptos clave
CHRE es el entorno de software en el que se ejecutan pequeñas apps nativas, llamadas
nanoapps, en un procesador de bajo consumo y que interactúan con el sistema subyacente
a través de la API común de CHRE. Para acelerar la implementación adecuada de las APIs de CHRE, se incluye una implementación de referencia multiplataforma de CHRE en AOSP. La implementación de referencia incluye código y abstracciones comunes para el hardware y el software subyacentes a través de una serie de capas de abstracción de plataforma (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 las nanoapps a través de las APIs del sistema
ContextHubManager
de acceso restringido.
En un nivel superior, se pueden establecer paralelismos entre la arquitectura de CHRE y Android en su conjunto. Sin embargo, existen algunas diferencias importantes:
- CHRE admite la ejecución solo de nanoapps desarrolladas en código nativo (C o C++); no se admite Java.
- Debido a las restricciones de recursos y las limitaciones de seguridad, CHRE no está abierto para el uso de apps para Android de terceros arbitrarias. Solo las apps de confianza del sistema pueden acceder a él.
También se debe hacer una distinción importante entre el concepto de CHRE y un centro de sensores. Si bien es común usar el mismo hardware para implementar el centro de sensores y CHRE, CHRE en sí no proporciona las capacidades de sensores que requiere la HAL de sensores de Android. CHRE está vinculado a la HAL del centro de contexto y actúa como cliente de un framework de sensores específico del dispositivo para recibir datos de sensores sin involucrar el AP.
Figura 1: Arquitectura del framework de CHRE
HAL del centro de contexto
La capa de abstracción de hardware (HAL) del centro de contexto es la interfaz entre el
framework de Android y la implementación de CHRE del dispositivo, definida en
hardware/interfaces/contexthub.
La HAL del centro de contexto define las APIs a través de las cuales el framework de Android descubre los centros de contexto disponibles y sus nanoapps, interactúa con esas nanoapps a través del paso de mensajes y permite que se carguen y descarguen nanoapps. Una implementación de referencia de la HAL del centro de contexto 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, prevalecerá la definición de HAL.
Inicialización
Cuando se inicia Android, el
ContextHubService
invoca la función getHubs() de HAL 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 demorar el inicio y debe mostrar un resultado preciso, ya que no se pueden introducir nuevos centros de contexto después.
Carga y descarga nanoapps
Un centro de contexto puede incluir un conjunto de nanoapps que se incluyen en la imagen del dispositivo y se cargan cuando se inicia CHRE. Se conocen como nanoapps precargadas y deben incluirse en la primera respuesta posible a queryApps().
La HAL del centro de contexto también admite la carga y descarga de nanoapps de forma dinámica en el tiempo de ejecución en
tiempo de ejecución, a través de las funciones loadNanoApp() y unloadNanoApp(). Las nanoapps se proporcionan a la HAL en un formato binario específico de la implementación de hardware y software de CHRE del dispositivo.
Si la implementación para cargar una nanoapp implica escribirla en una memoria no volátil, como el almacenamiento flash conectado al procesador que ejecuta CHRE, la implementación de CHRE siempre debe iniciarse con estas nanoapps dinámicas en el estado inhabilitado. Esto significa que no se ejecuta ninguno de los códigos de la nanoapp hasta que se recibe una solicitud enableNanoapp() a través de la HAL. Las nanoapps precargadas se pueden inicializar en el estado habilitado.
Reinicios del centro de contexto
Si bien no se espera que CHRE se reinicie durante el funcionamiento 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 de forma independiente de Android. La HAL notifica a Android a través del evento RESTARTED, que debe enviar solo después de que se haya reinicializado CHRE hasta el punto en que pueda aceptar solicitudes nuevas, como queryApps().
Descripción general del sistema CHRE
CHRE está diseñado en torno a una arquitectura basada en eventos, en la que la unidad principal de procesamiento es un evento que se pasa al punto de entrada de control de eventos de una nanoapp. Si bien el framework de CHRE puede ser de subprocesos múltiples, 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 a través de una devolución de llamada proporcionada en una llamada anterior a la API de CHRE, y las nanoapps interactúan con el framework de CHRE y el sistema subyacente a través de la API de CHRE. La API de CHRE proporciona un conjunto de capacidades básicas, así como funciones para acceder a señales contextuales, incluidos sensores, GNSS, Wi-Fi, WWAN y audio, y se puede extender con capacidades adicionales específicas del proveedor para que las usen las nanoapps específicas del proveedor.
Sistema de compilación
Si bien la HAL del centro de contexto y otros componentes necesarios del AP se compilan junto con Android, el código que se ejecuta dentro de CHRE puede tener requisitos que lo hagan 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 nanoapps y, de manera opcional, el framework de CHRE en bibliotecas que se pueden integrar con el sistema. Los fabricantes de dispositivos 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 está escrita en el estándar de lenguaje C99, y la implementación de referencia usa un subconjunto restringido de C++11 adecuado para apps 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 nanoapp y el sistema. Está diseñada para que el código de nanoapps sea compatible en todos los dispositivos que admiten CHRE, lo que significa que no es necesario modificar el código fuente de una nanoapp para admitir un nuevo tipo de dispositivo, aunque es posible que deba volver a compilarse específicamente para el conjunto de instrucciones del procesador del dispositivo de destino o la interfaz binaria de la aplicación (ABI). La arquitectura de CHRE y el diseño de la API también garantizan que las nanoapps sean compatibles con archivos binarios en diferentes versiones de la API de CHRE, lo que significa que no es necesario volver a compilar una nanoapp para que se ejecute en un sistema que implementa una versión diferente de la API de CHRE en comparación con la API de destino con la que se compila la nanoapp. En otras palabras, si un archivo binario de nanoapp se ejecuta en un dispositivo que admite la API de CHRE v1.3 y ese dispositivo se actualiza para admitir la API de CHRE v1.4, el mismo archivo binario de nanoapp sigue funcionando. Del mismo modo, la nanoapp se puede ejecutar 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, posiblemente con una degradación de funciones correcta.
Las versiones nuevas de la API de CHRE se lanzan junto con Android. Sin embargo, como la implementación de CHRE forma parte de la implementación del proveedor, la versión de la API de CHRE compatible con 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 de HIDL de Android,
la API de CHRE sigue el control de versiones semántico.
La versión principal indica la compatibilidad binaria, mientras que la versión secundaria se incrementa cuando se introducen funciones compatibles con versiones anteriores. La API de CHRE incluye anotaciones de código fuente para identificar qué versión introdujo una función o un 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 de chreGetVersion(), que indica cuándo se realizan correcciones de errores o actualizaciones secundarias en la implementación.
Para obtener resúmenes de cada versión, consulta version.h.
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 principales en todas las implementaciones de CHRE. Esto incluye las APIs principales del sistema, como las que se usan para configurar temporizadores, enviar y recibir mensajes a clientes en el procesador de aplicaciones, registrar y otras. Para obtener más detalles, consulta los encabezados de la API.
Además de las funciones principales del sistema codificadas en la API de CHRE, también hay funciones obligatorias de nivel del sistema CHRE especificadas en el nivel de HAL del centro de contexto. La más importante de ellas es la capacidad de cargar y descargar nanoapps de forma dinámica.
Biblioteca estándar de C/C++
Para minimizar el uso de memoria y la complejidad del sistema, las implementaciones de CHRE deben admitir solo un subconjunto de las bibliotecas estándar de C y C++, y las funciones de lenguaje que requieren compatibilidad con el tiempo de ejecución. Siguiendo estos principios, algunas funciones se excluyen de forma explícita debido a sus dependencias de memoria y extensas a nivel del SO, y otras porque se reemplazan por APIs más adecuadas específicas de CHRE. Si bien no se trata de una lista exhaustiva, las siguientes capacidades no están destinadas a estar disponibles para las nanoapps:
- Excepciones de C++ y información de tipo de tiempo de ejecución (RTTI)
- Compatibilidad con subprocesos múltiples de la biblioteca estándar, incluidos los encabezados de C++11
<thread>,<mutex>,<atomic>,<future> - Bibliotecas de entrada/salida estándar de C y C++
- Biblioteca de plantillas estándar (STL) de C++
- 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 usan inherentemente la asignación dinámica, comostd::unique_ptr - Compatibilidad con la localización y los 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 host, incluidos
system,getenv - POSIX y otras bibliotecas que no se incluyen en los estándares de lenguaje C99 o C++11
En muchos casos, las capacidades equivalentes están disponibles en las funciones de la API de CHRE y las bibliotecas de utilidades. Por ejemplo, chreLog se puede usar para el registro de depuración orientado al sistema logcat de Android, en el que un programa más tradicional podría usar printf o std::cout.
Por el contrario, se requieren algunas capacidades de la biblioteca estándar. Depende de la implementación de la plataforma exponerlas a través de bibliotecas estáticas para su inclusión en un archivo binario de nanoapp o mediante la vinculación dinámica entre la nanoapp y el sistema. Esto incluye, entre otros, software y servicios como los siguientes:
- Utilidades de cadenas y arrays:
memcmp,memcpy,memmove,memset,strlen Biblioteca de matemáticas: Funciones de punto flotante de precisión simple de uso frecuente:
- Operaciones básicas:
ceilf,fabsf,floorf,fmaxf,fminf,fmodf,roundf,lroundf,remainderf - Funciones exponenciales y de potencia:
expf,log2f,powf,sqrtf - Funciones trigonométricas e hiperbólicas:
sinf,cosf,tanf,asinf,acosf,atan2f,tanhf
- Operaciones básicas:
Si bien algunas plataformas subyacentes admiten capacidades adicionales, una nanoapp 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.
Funciones 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 funciones no sean necesarias para admitir una implementación de CHRE compatible, es posible que se requieran para admitir una nanoapp en particular. Incluso si una plataforma no admite un conjunto determinado de APIs, las nanoapps que hacen referencia a esas funciones deben poder compilarse y cargarse.
Sensores
La API de CHRE proporciona la capacidad de solicitar datos de sensores, incluidos el acelerómetro, el giroscopio, el magnetómetro, el sensor de luz ambiente y la proximidad. Estas APIs están diseñadas para proporcionar un conjunto de funciones similar a las APIs de 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 mucho más bajo y de menor latencia en comparación con la ejecución en el AP.
GNSS
CHRE proporciona APIs para solicitar datos de ubicación de un sistema global de navegación por satélite (GNSS), incluido el 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 vínculo directo con el subsistema GNSS, se reduce la energía en comparación con las solicitudes GNSS basadas en AP, ya que el AP puede permanecer inactivo durante todo el ciclo de vida de una sesión de ubicación.
Wi-Fi
CHRE proporciona la capacidad de interactuar con el chip Wi-Fi, principalmente para fines de ubicación. Si bien GNSS funciona bien para ubicaciones al aire libre, los resultados de los análisis 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 análisis, CHRE puede escuchar los resultados de los análisis de Wi-Fi que realiza el firmware de Wi-Fi para fines de conectividad, que, por lo general, no se entregan al AP por motivos de energía. Aprovechar los análisis de conectividad para fines contextuales ayuda a reducir la cantidad total de análisis de Wi-Fi realizados, lo que ahorra energía.
Se agregó compatibilidad con Wi-Fi en la API de CHRE v1.1, incluida la capacidad de supervisar los resultados de los análisis y activar los análisis a pedido. Estas capacidades se extendieron en la versión 1.2 con la capacidad de realizar mediciones del tiempo de ida y vuelta (RTT) en 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 proporciona la capacidad de recuperar información de identificación de celdas para la celda de servicio y sus vecinas, que suele usarse para fines de ubicación de grano grueso.
Audio
CHRE puede procesar lotes de datos de audio de un micrófono de bajo consumo, que suele aprovechar el hardware que se usa para implementar la HAL de SoundTrigger. El procesamiento de datos de audio en CHRE puede permitir que se fusionen con otros datos, como los sensores de movimiento.
Bluetooth
CHRE proporciona APIs que admiten un subconjunto de la funcionalidad de Bluetooth que se beneficia de la descarga de bajo consumo. CHRE permite que las nanoapps realicen análisis de BLE, supervisen RSSI y procesen datos de anuncios de BLE sin activar el AP. Además, la propiedad de una conexión de socket Bluetooth establecida se puede mover al dominio de descarga, lo que requiere menos energía para el mantenimiento y permite que las nanoapps se comuniquen a través de la conexión de socket BLE descargada.
Implementación de referencia
El código de referencia para el framework de CHRE se incluye 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 esta base de código para garantizar la coherencia y acelerar la adopción de nuevas capacidades. Este código se puede ver como un análogo al framework principal de Android, ya que es una implementación de código abierto de las APIs que usan las apps, que sirve como línea de base y estándar para la compatibilidad. Si bien se puede personalizar y extender con capacidades específicas del proveedor, se recomienda 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 usa 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, consulta el
README
incluido en el system/chre proyecto.