Environnement d'exécution Context Hub (CHRE)

Les smartphones sont équipés d'un certain nombre de processeurs, chacun étant optimisé pour les performances différentes tâches. Cependant, Android ne s'exécute que sur un seul processeur: les applications processeur (PA). Le point d'accès est réglé pour offrir d'excellentes performances pour l'écran sur écran comme les jeux vidéo, mais il est trop gourmand en énergie pour prendre en charge des fonctionnalités nécessitent de traiter en rafale fréquemment et fréquemment, même lorsque l'écran est désactivé. Les processeurs plus petits sont capables de gérer ces charges de travail plus efficacement, accomplissent leurs tâches sans répercussion notable sur l'autonomie de la batterie. Toutefois, les environnements logiciels de ces processeurs à faible consommation d'énergie sont plus limités et peuvent varient considérablement, ce qui complique le développement multiplate-forme.

L'environnement d'exécution Context Hub (CHRE) fournit une plate-forme commune pour exécuter sur un processeur à faible consommation d'énergie, à l'aide d'une API compatible avec l'intégration. CHRE facilite la tâche des OEM d'appareils et de leurs de décharger le point d'accès, d'économiser la batterie et d'améliorer de l'expérience utilisateur, et ils offrent une classe les fonctionnalités contextuelles, en particulier celles qui impliquent l'application le machine learning à la détection ambiante.

Concepts clés

CHRE est l'environnement logiciel dans lequel les petites applications natives, appelées nanoapps, s'exécutent sur un processeur à faible consommation d'énergie et interagissent avec via l'API CHRE commune. Pour accélérer la mise en œuvre les API CHRE, une implémentation de référence multiplate-forme de CHRE est incluse dans AOSP. L'implémentation de référence inclut du code commun et des abstractions pour le du matériel et des logiciels sous-jacents grâce à une série de couches d'abstraction de la plate-forme. (PAL). Les nanoapplications sont presque toujours liées à une ou plusieurs applications clientes exécutées dans Android, qui interagissent avec les applications CHRE et les nanoapplications via l'accès restreint ContextHubManager aux API système.

De manière générale, il est possible de faire le parallèle entre l'architecture CHRE et Android dans sa globalité. Il existe toutefois quelques différences importantes:

  • CHRE ne permet d'exécuter que des nanoapplications développées en code natif (C ou C++); Java n'est pas pris en charge.
  • En raison de contraintes de ressources et de limites de sécurité, CHRE n'est pas ouvert pour qu'elles soient utilisées par des applications Android tierces arbitraires. Seules les applications approuvées par le système y accéder.

Il faut également distinguer le concept de CHRE et un hub de capteurs. Bien qu'il soit courant d'utiliser le même matériel pour implémenter le le hub de capteurs et le CHRE, CHRE lui-même ne fournit pas les capacités des capteurs requises par les capteurs Android HAL : CHRE est lié à le HAL du hub contextuel, qui agit en tant que client d'un capteur spécifique à l'appareil pour recevoir les données des capteurs sans impliquer le point d'accès.

Architecture du framework CHRE

Figure 1 : Architecture du framework CHRE

HAL du hub contextuel

La couche d'abstraction matérielle (HAL) de Context Hub est l'interface entre Framework Android et l'implémentation CHRE de l'appareil, définie à l'adresse hardware/interfaces/contexthub Le HAL du hub contextuel définit les API via lesquelles le framework Android découvre les hubs contextuels disponibles et leurs nano-applications, interagit avec ces nanoapps via la transmission de messages, et permet de les charger et non chargées. Implémentation de référence du HAL du hub contextuel qui fonctionne avec mise en œuvre de référence de CHRE est disponible à l'adresse system/chre/host

En cas de conflit entre cette documentation et la définition HAL, le La définition HAL est prioritaire.

Initialisation

Au démarrage d'Android, Service ContextHub appelle la fonction HAL getHubs() pour déterminer si des hubs de contexte sont disponibles sur l'appareil. Comme il s'agit d'un appel unique bloquant, il doit se terminer rapidement pour éviter de retarder le démarrage, et il doit renvoyer un résultat précis, les hubs contextuels ne peuvent pas être introduits par la suite.

Charger et décharger des nanoapps

Un hub contextuel peut inclure un ensemble de nanoapplications incluses dans l'appareil. et sont chargés au démarrage de l'opération CHRE. On les appelle nanoapplications préchargées, et doit être inclus dans la première réponse possible à queryApps().

Le HAL de Context Hub permet également de charger et décharger des nanoapplications de manière dynamique via les fonctions loadNanoApp() et unloadNanoApp(). Nanoapplications sont fournies au HAL dans un format binaire spécifique au matériel CHRE et mise en œuvre logicielle de l'appareil.

Si l'implémentation de chargement d'une nanoapplication implique de l'écrire dans un environnement non volatile (par exemple, une mémoire de stockage flash associée au processeur exécutant CHRE), L'implémentation CHRE doit toujours démarrer avec ces nano-applications dynamiques dans désactivé. Cela signifie qu'aucun code de nanoapp n'est exécuté tant qu'un La requête enableNanoapp() est reçue via le HAL. Les nanoapplications préchargées s'initialisent à l'état activé.

Redémarrages du hub contextuel

Bien qu'il ne soit pas prévu que CHRE redémarre en fonctionnement normal, il peuvent être nécessaires pour faire face à des conditions inattendues, telles qu'une tentative de accéder à une adresse mémoire non mappée. Dans ces situations, CHRE redémarre indépendamment d'Android. Le HAL en informe Android via le RESTARTED, qu'il ne doit envoyer qu'après la réinitialisation de CHRE point qu'il peut accepter de nouvelles requêtes, comme queryApps().

Présentation du système CHRE

CHRE est conçu autour d'une architecture basée sur des événements, où l'unité principale de Le calcul est un événement transmis au point d'entrée de gestion des événements d'une application nano. Alors que le framework CHRE peut être multithread, une nanoapplication donnée n'est jamais exécutée depuis plusieurs threads en parallèle. Le framework CHRE interagit avec une application nano donnée. via l'un des trois points d'entrée de nanoapp (nanoappStart(), nanoappHandleEvent() et nanoappEnd()), soit par le biais d'un rappel fourni dans une appel d'API CHRE précédent, et les nanoapps interagissent avec le framework CHRE et système sous-jacent via l'API CHRE. L'API CHRE fournit un ensemble et des installations pour accéder aux signaux de contexte, GNSS, Wi-Fi, WWAN et audio, et peut être étendu des fonctionnalités propres au fournisseur pour une utilisation par des nanoapplications spécifiques à un fournisseur.

Système de compilation

Le HAL du hub contextuel et les autres composants nécessaires côté point d'accès sont parallèlement à Android, le code exécuté dans CHRE peut avoir des exigences qui le rendent incompatible avec le système de compilation Android, comme la nécessité d'une ou une chaîne d'outils. Par conséquent, le projet CHRE dans AOSP offre une compilation simplifiée basé sur GNU Make pour compiler des nano-applications et, éventuellement, le framework CHRE dans des bibliothèques qui peuvent être intégrées au système. Appareil les fabricants qui prennent en charge CHRE doivent intégrer la prise en charge du système de compilation pour leurs appareils cibles dans AOSP.

L'API CHRE est écrite dans la norme de langage C99, et la documentation de référence utilise un sous-ensemble restreint de C++11 adapté aux ressources limitées applications.

API CHRE

L'API CHRE est un ensemble de fichiers d'en-tête C qui définissent le logiciel l'interface entre une application nano et le système. Il est conçu pour créer des nanoapplications sur tous les appareils prenant en charge CHRE, le code source d'une application nano n'a pas besoin d'être modifié pour être compatible avec un nouvel appareil. bien qu'il doive être recompilé spécifiquement pour le ensemble d'instructions du processeur ou interface binaire d'application (ABI). La CHRE et la conception des API assurent également la compatibilité binaire des nanoapplications pour les différentes versions de l'API CHRE, ce qui signifie qu'une nanoapplication doivent être recompilées pour fonctionner sur un système qui implémente une version différente de l'API CHRE par rapport à l'API cible avec laquelle la nanoapplication est compilée. En d'autres termes, si un binaire nanoapp s'exécute sur un appareil compatible avec l'API CHRE, version 1.3. Cet appareil est mis à niveau pour être compatible avec la version 1.4 de l'API CHRE, la même application nano continue de fonctionner. De même, nanoapp peut s'exécuter sur l'API CHRE version 1.2, et peut déterminer, au moment de l'exécution, si des fonctionnalités allant de la version 1.3 de l'API atteindre son utilisation, ou déterminer s'il peut fonctionner, potentiellement la dégradation des caractéristiques.

De nouvelles versions de l'API CHRE sont publiées parallèlement à Android, mais comme le CHRE fait partie du processus l'implémentation des fournisseurs, la version de l'API CHRE compatible avec un appareil n'est pas nécessairement liée à Version d'Android

Résumé de la version

Comme Schéma de gestion des versions Android HIDL l'API CHRE suit la gestion sémantique des versions. La version majeure indique une compatibilité binaire, tandis que la version mineure est lorsque des fonctionnalités rétrocompatibles sont introduites. API CHRE inclut des annotations de code source pour identifier la version ayant introduit une fonction ou un paramètre, par exemple @since v1.1.

L'implémentation CHRE expose également une version de correctif spécifique à la plate-forme via chreGetVersion(), qui indique lorsque des corrections de bugs ou des mises à jour mineures sont effectuées dans l'implémentation.

Version 1.0 (Android 7)

Inclut la prise en charge des capteurs et des principales fonctionnalités des applications nano, telles que les événements et minuteurs.

Version 1.1 (Android 8)

Introduction des fonctionnalités de localisation via l'emplacement GNSS et les mesures brutes Recherche de réseaux Wi-Fi, informations sur les réseaux mobiles et améliorations générales pour permettre la communication de nanoapplication à nanoapplication, entre autres améliorations.

Version 1.2 (Android 9)

Ajout de la prise en charge des données provenant d'un microphone basse consommation, du DAR Wi-Fi, du point d'accès des notifications de réveil et de sommeil, et d'autres améliorations.

Version 1.3 (Android 10)

Amélioration des fonctionnalités liées aux données d'étalonnage des capteurs et prise en charge de vider les données des capteurs par lot à la demande, définir le type de capteur de détection de pas et étend les événements de localisation GNSS avec des champs de précision supplémentaires.

Version 1.4 (Android 11)

Ajout de la prise en charge des informations sur les cellules 5G, de l'empreinte de débogage nanoapp et d'autres et d'améliorations.

Fonctionnalités système obligatoires

Les sources de signaux de contexte, comme les capteurs, sont classées fonctionnalités principales, quelques fonctions essentielles sont requises dans tous les domaines CHRE mises en œuvre. Cela inclut les API système principales, telles que celles permettant de définir des minuteries, l'envoi et la réception de messages aux clients sur le processeur d'applications, la journalisation, etc. Pour plus d'informations, consultez les En-têtes d'API :

Outre les principales fonctionnalités système codifiées dans l'API CHRE, les fonctionnalités CHRE obligatoires au niveau du système spécifiées au niveau HAL du hub de contexte. La le plus important est la possibilité de charger et décharger dynamiquement nanoapps.

Bibliothèque standard C/C++

Pour minimiser l'utilisation de la mémoire et la complexité du système, les implémentations CHRE sont ne doit prendre en charge qu'un sous-ensemble des bibliothèques C et C++ standards et nécessitant une compatibilité avec les environnements d'exécution. Conformément à ces principes, certaines fonctionnalités sont explicitement exclues en raison de leur mémoire et de l'étendue de leur OS au niveau les dépendances, et d’autres parce qu’elles sont supplantées par des API spécifiques à CHRE. Bien qu'il ne s'agisse pas d'une liste exhaustive, les éléments suivants ne sont pas destinées à être mises à la disposition des nanoapplications:

  • Informations sur les exceptions C++ et le type d'exécution (RTTI)
  • Compatibilité avec le multithreading des bibliothèques standards, y compris les en-têtes C++11 <thread>, <mutex>, <atomic> et <future>
  • Bibliothèques d'entrées/sorties standards C et C++
  • Bibliothèque de modèles standard (STL) C++
  • Bibliothèque d'expressions régulières standards C++
  • Allocation de mémoire dynamique via des fonctions standards (par exemple, malloc, calloc, realloc, free, operator new) et autre standard fonctions de bibliothèque qui utilisent intrinsèquement l'allocation dynamique, comme std::unique_ptr
  • Localisation et compatibilité avec les caractères Unicode
  • Bibliothèques de dates et d'heures
  • Fonctions modifiant le flux de programme normal, y compris <setjmp.h>, <signal.h>, abort et std::terminate
  • Accéder à l'environnement hôte, y compris system et getenv
  • POSIX et autres bibliothèques non incluses dans les langages C99 ou C++11 standards

Dans de nombreux cas, des fonctionnalités équivalentes sont disponibles à partir des fonctions de l'API CHRE. et bibliothèques d'utilitaires. Par exemple, chreLog peut être utilisé pour la journalisation des données de débogage. ciblant le système Android Logcat, où un programme plus traditionnel pourrait utilisez printf ou std::cout.

En revanche, certaines fonctionnalités de la bibliothèque standard sont requises. C'est à vous pour les présenter via des bibliothèques statiques en vue de leur inclusion dans un binaire nanoapp, ou via une association dynamique entre nanoapp et le système. Ce Cela inclut, sans s'y limiter, les éléments suivants:

  • Utilitaires de chaîne et de tableau: memcmp, memcpy, memmove, memset, strlen

  • Bibliothèque mathématique: fonctions à virgule flottante à simple précision couramment utilisées:

    • Opérations de base: ceilf, fabsf, floorf, fmaxf, fminf, fmodf roundf, lroundf et remainderf
    • Fonctions exponentielles et de puissance: expf, log2f, powf, sqrtf
    • Fonctions trigonométriques et hyperboliques: sinf, cosf, tanf, asinf, acosf, atan2f et tanhf

Même si certaines plates-formes sous-jacentes prennent en charge des fonctionnalités supplémentaires, n'est pas considéré comme portable entre les implémentations CHRE, sauf si elle limite son dépendances externes aux fonctions de l'API CHRE et à la bibliothèque standard approuvée fonctions.

Fonctionnalités en option

Pour promouvoir le matériel et les logiciels, l'API CHRE est divisée en domaines de fonctionnalités : qui sont considérés comme facultatifs du point de vue de l'API. Bien que ces fonctionnalités peuvent ne pas être nécessaires pour prendre en charge une implémentation CHRE compatible, ils peuvent être nécessaires pour assurer la compatibilité d'une application nano spécifique. Même si une plate-forme n'accepte pas un ensemble donné d'API, les nanoapplications qui y font référence doivent pouvoir créer et charger les données.

Capteurs

L'API CHRE permet de demander des données à des capteurs, accéléromètre, gyroscope, magnétomètre, capteur de luminosité ambiante et proximité. Ces API sont destinées à fournir un ensemble de fonctionnalités semblables à celles des capteurs Android API, y compris la prise en charge du traitement par lot des échantillons de capteurs pour réduire la consommation d'énergie Le traitement des données des capteurs dans CHRE permet de réduire considérablement la consommation d'énergie et la latence. des signaux de mouvement par rapport à la course sur le point d'accès.

GNSS

CHRE fournit des API permettant de demander des données de localisation à une navigation mondiale satellite (GNSS), y compris le GPS et d'autres constellations satellites. Ce inclut les demandes de correction périodique de la position, ainsi que les données de mesure brutes, bien que les deux sont des capacités indépendantes. Étant donné que CHRE dispose d'un lien direct vers le GNSS, la puissance est réduite par rapport aux requêtes GNSS basées sur le point d'accès, car le point d'accès peut rester endormi(e) tout au long du cycle de vie d'une session de localisation.

Wi-Fi

CHRE permet d'interagir avec la puce Wi-Fi, principalement pour de localisation. Si le GNSS fonctionne bien en extérieur, les résultats Les recherches de réseaux Wi-Fi peuvent fournir des informations de localisation précises à l'intérieur et dans les dans différentes zones géographiques. En plus d'éviter le coût d'activation du point d'accès pour une analyse, CHRE peut écouter les résultats des recherches de réseaux Wi-Fi effectuées à des fins de connectivité, qui ne sont généralement pas transmises au point d'accès pour des raisons d'alimentation. L'exploitation des analyses de connectivité à des fins contextuelles aide pour réduire le nombre total de recherches de réseaux Wi-Fi effectuées et économiser de l'énergie.

La prise en charge du Wi-Fi a été ajoutée dans la version 1.1 de l'API CHRE, avec la possibilité de surveiller et déclencher des analyses à la demande. Ces capacités ont été étendues dans v1.2 avec la possibilité d'effectuer Délai aller-retour (DAR) des mesures par rapport aux points d'accès compatibles avec la fonctionnalité, ce qui permet une détermination précise de la position relative.

WWAN

L'API CHRE permet de récupérer des informations d'identification de cellule pour la cellule de diffusion et ses voisines, ce qui est généralement utilisé à des fins de localisation approximative.

Audio

CHRE peut traiter des lots de données audio à partir d'un micro de faible puissance, ce qui utilise généralement le matériel utilisé pour implémenter le HAL de SoundTrigger. En cours de traitement données audio dans CHRE peuvent permettre de les fusionner avec d'autres données, comme les mouvements capteurs.

Implémentation de référence

Le code de référence du framework CHRE est inclus dans AOSP dans le system/chre. , implémenté en C++11. Bien que cela ne soit pas strictement obligatoire, il est recommandé pour toutes les implémentations CHRE soient basées sur ce codebase, pour garantir la cohérence et à accélérer l'adoption de nouvelles capacités. Ce code est visible Il s'agit d'une analogie avec le framework Android principal, dans la mesure où il s'agit des API utilisées par les applications, servant de référence et pour assurer la compatibilité. Bien qu'il puisse être personnalisé et étendu avec des il est recommandé de maintenir le code commun au plus près de référence que possible. Semblable aux HAL d'Android, la référence CHRE utilise diverses abstractions de plate-forme pour lui permettre de s'adapter tout appareil répondant à la configuration minimale requise.

Pour obtenir des informations techniques et un guide de transfert, consultez la README inclus dans le projet system/chre.