Google se compromete a impulsar la igualdad racial para las comunidades afrodescendientes. Obtén información al respecto.

Entorno de tiempo de ejecución de Context Hub (CHRE)

Los teléfonos inteligentes 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á ajustado para ofrecer un gran rendimiento para casos de uso con pantalla encendida, como los juegos, pero consume demasiada energía para admitir funciones que requieren ráfagas breves y frecuentes de procesamiento 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 sencilla, estandarizada e integrada. 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 habiliten una clase de características siempre activas y conscientes del contexto, especialmente aquellas que involucran la aplicación de máquinas. aprender a la detección ambiental.

Conceptos clave

CHRE es el entorno de software en pequeñas aplicaciones nativas, llamados nanoapps, se ejecutan en un procesador de bajo consumo e interactuar con el sistema subyacente a través de la API CHRE común. Para acelerar la implementación adecuada de las API de CHRE, en AOSP se incluye una implementación de referencia multiplataforma de CHRE. La implementación de referencia incluye código común y abstracciones al hardware y software subyacentes a través de una serie de capas de abstracción de plataforma (PAL). Nanoapps están casi siempre ligados a una o más aplicaciones cliente que se ejecutan en Android, que interactúan con CHRE y nanoapps a través de acceso restringido ContextHubManager API del sistema.

A un alto nivel, se pueden establecer paralelos 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 restricciones de recursos y limitaciones de seguridad, CHRE no está abierto para su uso por aplicaciones de Android arbitrarias de terceros. Solo las aplicaciones de confianza del sistema pueden acceder a él.

También se debe hacer una distinción importante entre el concepto de CHRE y un concentrador de sensores. Si bien es común utilizar el mismo hardware para implementar el centro del sensor y CHRE, sí CHRE no proporciona la funcionalidad del sensor requerido por el androide Sensores HAL . CHRE está vinculado al Context Hub HAL y actúa como cliente de un marco de sensor específico del dispositivo para recibir datos del sensor sin involucrar al AP.

Arquitectura del marco CHRE

Configuración del marco Figura 1. CHRE

Centro de contexto HAL

El contexto Hub capa de abstracción de hardware (HAL) es la interfaz entre el marco y la aplicación Android CHRE del dispositivo, que se define 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 nanoapps, interactúa con esas nanoapps a través del paso de mensajes y permite que las nanoapps se carguen y descarguen. Una implementación de referencia del Contexto Hub HAL que trabaja con la implementación de referencia de CHRE está disponible en el 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 las botas hasta Android, el ContextHubService invoca el getHubs() de función HAL para determinar si los concentradores de contexto están disponibles en el dispositivo. Esta es una llamada única de bloqueo, por lo que debe completarse rápidamente para evitar retrasos en el arranque, y debe devolver un resultado preciso, ya que no se pueden introducir nuevos centros de contexto después.

Carga y descarga de nanoapps

Un centro de contexto puede incluir un conjunto de nanoaplicaciones que se incluyen en la imagen del dispositivo y se cargan cuando se inicia CHRE. Estos son conocidos como nanoapps precargados, y deben ser incluidos en la primera respuesta posible a queryApps() .

El contexto Hub HAL también soporta carga y descarga nanoapps dinámicamente en tiempo de ejecución, a través de la loadNanoApp() y unloadNanoApp() funciones. 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 adjunto al procesador que ejecuta CHRE, entonces la implementación de CHRE siempre debe arrancar con estas nanoaplicaciones dinámicas en el estado deshabilitado. Esto significa que ninguno de código del nanoapp se ejecuta hasta que un enableNanoapp() solicitud es recibida a través de la HAL. Las nanoaplicaciones precargadas se pueden inicializar en el estado habilitado.

Se reinicia el centro de contexto

Si bien no se espera que CHRE se reinicie durante el curso del 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 independientemente de Android. El HAL notifica Android de este a través de la RESTARTED evento, que se debe enviar sólo después CHRE se ha reinicializado hasta el punto de que puede aceptar solicitudes nuevas, tales como queryApps() .

Descripción general del sistema CHRE

CHRE está diseñado en torno a una arquitectura impulsada por eventos, donde la unidad principal de cálculo es un evento que se pasa al punto de entrada de manejo de eventos de una nanoapp. Si bien el marco CHRE puede ser multiproceso, una nanoaplicación determinada nunca se ejecuta desde múltiples subprocesos en paralelo. Los interactúa marco CHRE con un nanoapp dado a través de uno de los tres puntos de entrada nanoapp ( nanoappStart() , nanoappHandleEvent() , y nanoappEnd() ) o a través de una devolución de llamada proporcionado en una llamada de API CHRE antes, y nanoapps interactuar con el marco CHRE y el sistema subyacente a través de la API CHRE. La API de CHRE proporciona un conjunto de funciones básicas, así como facilidades 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 su uso por nanoaplicaciones específicas del proveedor. .

Sistema de construcción

Si bien Context Hub HAL y otros componentes necesarios del lado AP se crean 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 construcción simplificado basado en GNU Make para compilar nanoapps 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 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 CHRE

La API CHRE es una colección de archivos de encabezado C que definen la interfaz de software entre una nanoapp y el sistema. Está diseñado para hacer que el código de nanoapps sea compatible en todos los dispositivos que admiten CHRE, lo que significa que el código fuente de una nanoapp no ​​necesita modificarse para admitir un nuevo tipo de dispositivo, aunque es posible que deba recompilarse específicamente para el procesador del dispositivo de destino. conjunto de instrucciones o interfaz binaria de aplicación (ABI). La arquitectura 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 no es necesario volver a compilar una nanoaplicación para ejecutarse 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 binario nanoapp se ejecuta en un dispositivo que admite CHRE API v1.3, y ese dispositivo se actualiza para admitir CHRE API v1.4, el mismo binario nanoapp sigue funcionando. De manera similar, la nanoapp 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 elegante degradación de características.

Las nuevas versiones de la API CHRE se liberan junto con Android, sin embargo, como la puesta en práctica CHRE es parte de la implementación del proveedor , la versión de la API CHRE apoyado en un dispositivo no está necesariamente ligada a una versión de Android.

Resumen de la versión

Al igual que el esquema de versiones Android HIDL , la API sigue CHRE versiones semántica . La versión principal indica compatibilidad binaria, mientras que la versión secundaria se incrementa cuando se introducen funciones compatibles con versiones anteriores. El API 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 aplicación CHRE también expone una versión parche específico de la plataforma a través chreGetVersion() , que indica cuándo correcciones de errores o actualizaciones menores se realizan en la aplicación.

Versión 1.0 (Android 7)

Incluye soporte para sensores y funcionalidad básica de nanoaplicaciones, como eventos y temporizadores.

Versión 1.1 (Android 8)

Presenta capacidades de ubicación a través de la 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 AP de activación / suspensión 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 de sensor por lotes a pedido, define el tipo de sensor de detección de pasos y extiende los eventos de ubicación GNSS con campos de precisión adicionales.

Versión 1.4 (Android 11)

Agrega soporte para información de celda 5G, volcado de depuración de nanoapp y otras mejoras.

Características obligatorias del sistema

Si bien las fuentes de señales contextuales, como los sensores, se clasifican en áreas de características opcionales, se requieren algunas funciones básicas en todas las implementaciones de CHRE. Esto incluye las API del sistema principal, como aquellas para configurar temporizadores, enviar y recibir mensajes a clientes en el procesador de aplicaciones, registro y otros. Para más detalles, ver los encabezados de la API .

Además de las características centrales del sistema codificadas en la API de CHRE, también hay características obligatorias de nivel de sistema de CHRE especificadas en el nivel de Context Hub HAL. El más significativo de ellos es la capacidad de cargar y descargar nanoapps de forma dinámica.

Biblioteca estándar 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 C y C ++ estándar y las características del lenguaje que requieren soporte de tiempo de ejecución. Siguiendo estos principios, algunas características se excluyen explícitamente debido a su memoria y / o dependencias extensas a nivel de 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 nanoapps:

  • Excepciones de C ++ e información de tipo de tiempo de ejecución (RTTI)
  • Multithreading biblioteca estándar de apoyo, incluyendo C ++ 11 cabeceras <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 dinámica de memoria a través de funciones estándar (por ejemplo, malloc , calloc , realloc , free , operator new ), y otras funciones de la biblioteca estándar que utilizan inherentemente asignación dinámica, como std::unique_ptr
  • Soporte de localización y caracteres Unicode
  • Bibliotecas de fecha y hora
  • Funciones que modifican el flujo normal del programa, incluyendo <setjmp.h> , <signal.h> , abort , std::terminate
  • Acceso al entorno de anfitrión, incluyendo 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 de la API de CHRE y / o bibliotecas de utilidades. Por ejemplo, chreLog se puede utilizar para el registro de depuración dirigida al sistema Logcat 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 su inclusión en un binario nanoapp, o mediante la vinculación dinámica entre la nanoapp y el sistema. Esto incluye, pero no se limita a:

  • Cuerda / utilidades matriz: 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
    • Las funciones exponenciales / potencia: expf , log2f , powf , sqrtf
    • Trigonométrica / funciones hiperbólicas: sinf , cosf , tanf , asinf , acosf , atan2f , tanhf

Si bien algunas plataformas subyacentes admiten funciones adicionales, una nanoapp no ​​se considera portátil en todas 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 características, 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 CHRE compatible, es posible que sean necesarias para admitir una nanoaplicación en particular. Incluso si una plataforma no es compatible con 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 sensores de Android, incluida la compatibilidad con muestras de sensores por lotes para reducir el consumo de energía. El procesamiento de los datos del sensor dentro de CHRE permite un procesamiento de señales de movimiento con una potencia mucho menor y una latencia más baja 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), incluido el GPS y otras constelaciones de satélites. Esto incluye solicitudes de arreglos de posición periódicos, así como datos de medición sin procesar, aunque ambos son capacidades independientes. Como CHRE tiene un enlace directo al subsistema GNSS, la energía se reduce en comparación con las solicitudes GNSS basadas en AP, porque el AP puede permanecer dormido 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 entregan al AP por razones de energía. Aprovechar los escaneos de conectividad con 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 extendieron en v1.2 con la capacidad de realizar de ida y vuelta Time (RTT) mediciones contra los puntos de acceso que soportan la característica, que permite la determinación de posición relativa exacta.

WWAN

La API de CHRE proporciona la capacidad de recuperar información de identificación de celda para la celda de servicio y sus vecinas, que generalmente se usa para propósitos de ubicación de grano grueso.

Audio

CHRE puede procesar lotes de datos de audio de un micrófono de baja potencia, que normalmente 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

Código de referencia para el marco CHRE está incluido en AOSP en el system/chre proyecto, 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 ayudar a garantizar la coherencia y acelerar la adopción de nuevas capacidades. Este código puede verse como un análogo al marco central de Android, ya que es una implementación de código abierto de las API que utilizan las aplicaciones, que sirve como base 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. Similar a las HAL de Android, la implementación de referencia CHRE utiliza varias abstracciones de plataforma para permitir que se adapte a cualquier dispositivo que cumpla con los requisitos mínimos.

Los datos técnicos y una guía de portabilidad, ver el README incluido en el system/chre proyecto.