Les smartphones contiennent un certain nombre de processeurs, chacun optimisé pour effectuer différentes tâches. Cependant, Android ne fonctionne que sur un seul processeur : le processeur d'applications (AP). L'AP est conçu pour offrir d'excellentes performances dans les cas d'utilisation sur écran tels que les jeux, mais il est trop gourmand en énergie pour prendre en charge des fonctionnalités qui nécessitent des rafales de traitement fréquentes et courtes à tout moment, même lorsque l'écran est éteint. Les processeurs plus petits sont capables de gérer ces charges de travail plus efficacement, accomplissant leurs tâches sans impact notable sur la durée de vie de la batterie. Cependant, les environnements logiciels de ces processeurs basse consommation sont plus limités et peuvent varier considérablement, ce qui rend le développement multiplateforme difficile.
Context Hub Runtime Environment (CHRE) fournit une plate-forme commune pour exécuter des applications sur un processeur basse consommation, avec une API simple, standardisée et intégrée. CHRE permet aux OEM d'appareils et à leurs partenaires de confiance de décharger le traitement du point d'accès, d'économiser la batterie et d'améliorer divers domaines de l'expérience utilisateur, et d'activer une classe de fonctionnalités toujours actives et contextuelles, en particulier celles impliquant l'application de la machine. apprentissage de la détection ambiante.
Concepts clés
CHRE est l'environnement logiciel dans lequel de petites applications natives, appelées nanoapps , s'exécutent sur un processeur basse consommation et interagissent avec le système sous-jacent via l'API CHRE commune. Pour accélérer la mise en œuvre appropriée des API CHRE, une implémentation de référence multiplateforme de CHRE est incluse dans AOSP. L'implémentation de référence comprend du code commun et des abstractions pour le matériel et les logiciels sous-jacents via une série de couches d'abstraction de plate-forme (PAL). Les nanoapplications sont presque toujours liées à une ou plusieurs applications clientes exécutées sous Android, qui interagissent avec CHRE et les nanoapplications via les API du système ContextHubManager à accès restreint.
À un niveau élevé, des parallèles peuvent être établis entre l’architecture de CHRE et Android dans son ensemble. Il existe cependant quelques distinctions importantes :
- CHRE prend en charge l'exécution uniquement 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 limitations de sécurité, CHRE n'est pas ouvert à l'utilisation d'applications Android tierces arbitraires. Seules les applications approuvées par le système peuvent y accéder.
Il existe également une distinction importante à faire entre le concept de CHRE et celui de hub de capteurs. Bien qu'il soit courant d'utiliser le même matériel pour implémenter le hub de capteurs et CHRE, CHRE lui-même ne fournit pas la fonctionnalité de capteur requise par Android Sensors HAL . CHRE est lié au Context Hub HAL et agit en tant que client d'un cadre de capteurs spécifique à l'appareil pour recevoir les données des capteurs sans impliquer le point d'accès.
Figure 1. Architecture du cadre CHRE
Centre de contexte HAL
La couche d'abstraction matérielle (HAL) de Context Hub est l'interface entre le framework Android et l'implémentation CHRE de l'appareil, définie dans hardware/interfaces/contexthub . Le Context Hub HAL définit les API à travers lesquelles le framework Android découvre les hubs de contexte disponibles et leurs nanoapplications, interagit avec ces nanoapplications via la transmission de messages et permet de charger et de décharger les nanoapplications. Une implémentation de référence de Context Hub HAL qui fonctionne avec l'implémentation de référence de CHRE est disponible sur system/chre/host .
En cas de conflit entre cette documentation et la définition HAL, la définition HAL prévaut.
Initialisation
Lorsque Android démarre, ContextHubService appelle la fonction getHubs() HAL pour déterminer si des hubs de contexte sont disponibles sur l'appareil. Il s'agit d'un appel unique et bloquant, il doit donc se terminer rapidement pour éviter de retarder le démarrage, et il doit renvoyer un résultat précis, car de nouveaux hubs de contexte ne peuvent pas être introduits par la suite.
Chargement et déchargement de nanoapplications
Un hub contextuel peut inclure un ensemble de nanoapplications incluses dans l'image de l'appareil et chargées au démarrage de CHRE. Celles-ci sont connues sous le nom de nanoapps préchargées et doivent être incluses dans la première réponse possible à queryApps() .
Le Context Hub HAL prend également en charge le chargement et le déchargement dynamique des nanoapps au moment de l'exécution, via les fonctions loadNanoApp() et unloadNanoApp() . Les nanoapps sont fournies au HAL dans un format binaire spécifique à l'implémentation matérielle et logicielle CHRE de l'appareil.
Si l'implémentation du chargement d'une nano-application implique son écriture dans une mémoire non volatile, telle qu'un stockage flash connecté au processeur qui exécute CHRE, alors l'implémentation de CHRE doit toujours démarrer avec ces nano-applications dynamiques à l'état désactivé. Cela signifie qu'aucun code de la nanoapp n'est exécuté jusqu'à ce qu'une requête enableNanoapp() soit reçue via HAL. Les nanoapplications préchargées peuvent s'initialiser dans l'état activé.
Le hub de contexte redémarre
Bien que CHRE ne soit pas censé redémarrer au cours d'un fonctionnement normal, il peut être nécessaire de se remettre de conditions inattendues, telles qu'une tentative d'accès à une adresse mémoire non mappée. Dans ces situations, CHRE redémarre indépendamment d'Android. Le HAL en informe Android via l'événement RESTARTED , qu'il doit envoyer uniquement après que CHRE ait été réinitialisé au point qu'il puisse accepter de nouvelles requêtes, telles que queryApps() .
Présentation du système CHRE
CHRE est conçu autour d'une architecture basée sur les événements, dans laquelle l'unité principale de calcul est un événement transmis au point d'entrée de gestion des événements d'une nanoapplication. Bien que le framework CHRE puisse être multithread, une nanoapp donnée n'est jamais exécutée à partir de plusieurs threads en parallèle. Le framework CHRE interagit avec une nanoapp donnée via l'un des trois points d'entrée nanoapp ( nanoappStart() , nanoappHandleEvent() et nanoappEnd() ) ou via un rappel fourni dans un appel API CHRE précédent, et les nanoapps interagissent avec le framework CHRE et le système sous-jacent via l’API CHRE. L'API CHRE fournit un ensemble de fonctionnalités de base ainsi que des fonctionnalités permettant d'accéder aux signaux contextuels, notamment les capteurs, le GNSS, le Wi-Fi, le WWAN et l'audio, et elle peut être étendue avec des fonctionnalités supplémentaires spécifiques au fournisseur pour une utilisation par des nanoapplications spécifiques au fournisseur. .
Système de construction
Bien que Context Hub HAL et d'autres composants côté AP nécessaires soient construits avec Android, le code qui s'exécute dans CHRE peut avoir des exigences qui le rendent incompatible avec le système de build Android, comme la nécessité d'une chaîne d'outils spécialisée. Par conséquent, le projet CHRE dans AOSP fournit un système de construction simplifié basé sur GNU Make pour compiler des nanoapplications et, éventuellement, le framework CHRE dans des bibliothèques pouvant être intégrées au système. Les fabricants d’appareils qui ajoutent la prise en charge de CHRE devraient intégrer la prise en charge du système de build pour leurs appareils cibles dans AOSP.
L'API CHRE est écrite selon la norme de langage C99 et l'implémentation de référence utilise un sous-ensemble restreint de C++11 adapté aux applications aux ressources limitées.
API CHRE
L'API CHRE est une collection de fichiers d'en-tête C qui définissent l'interface logicielle entre une nanoapplication et le système. Il est conçu pour rendre le code des nanoapplications compatible sur tous les appareils prenant en charge CHRE, ce qui signifie que le code source d'une nanoapplication n'a pas besoin d'être modifié pour prendre en charge un nouveau type d'appareil, bien qu'il puisse devoir être recompilé spécifiquement pour le processeur de l'appareil cible. jeu d’instructions ou interface binaire d’application (ABI). L'architecture CHRE et la conception de l'API garantissent également que les nanoapplications sont compatibles binairement entre différentes versions de l'API CHRE, ce qui signifie qu'une nanoapplication n'a pas besoin d'être recompilée pour s'exécuter sur un système qui implémente une version différente de l'API CHRE par rapport à l'API cible sur laquelle la nanoapp est compilée. En d’autres termes, si un binaire nanoapp s’exécute sur un appareil prenant en charge l’API CHRE v1.3 et que cet appareil est mis à niveau pour prendre en charge l’API CHRE v1.4, le même binaire nanoapp continue de fonctionner. De même, la nanoapp peut s'exécuter sur l'API CHRE v1.2 et déterminer au moment de l'exécution si elle nécessite les fonctionnalités de l'API v1.3 pour atteindre ses fonctionnalités, ou si elle peut fonctionner, potentiellement avec une dégradation progressive des fonctionnalités.
De nouvelles versions de l'API CHRE sont publiées parallèlement à Android. Cependant, comme l'implémentation de CHRE fait partie de l' implémentation du fournisseur , la version de l'API CHRE prise en charge sur un appareil n'est pas nécessairement liée à une version d'Android.
Résumé des versions
Comme le schéma de versionnage Android HIDL , l'API CHRE suit le versionnement sémantique . La version majeure indique la compatibilité binaire, tandis que la version mineure est incrémentée lorsque des fonctionnalités rétrocompatibles sont introduites. L'API CHRE comprend des annotations de code source pour identifier quelle version a 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 quand 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 fonctionnalités de base des nanoapps, telles que les événements et les minuteries.
Version 1.1 (Android 8)
Présente des fonctionnalités de localisation via la localisation GNSS et les mesures brutes, la numérisation Wi-Fi et les informations sur le réseau cellulaire, ainsi que des améliorations générales pour permettre la communication nano-application à nano-application et d'autres améliorations.
Version 1.2 (Android 9)
Ajoute la prise en charge des données provenant d'un microphone à faible consommation, de la portée Wi-Fi RTT, des notifications de réveil/veille AP et d'autres améliorations.
Version 1.3 (Android 10)
Améliore les capacités liées aux données d'étalonnage des capteurs, ajoute la prise en charge du vidage des données de capteur par lots à la demande, définit le type de capteur de détection par étapes et étend les événements de localisation GNSS avec des champs de précision supplémentaires.
Version 1.4 (Android 11)
Ajoute la prise en charge des informations sur les cellules 5G, du vidage de débogage nanoapp et d'autres améliorations.
Fonctionnalités système obligatoires
Alors que les sources de signaux contextuels, comme les capteurs, sont classées en zones de fonctionnalités facultatives, quelques fonctions de base sont requises dans toutes les implémentations de CHRE. Cela inclut les API du système de base, telles que celles permettant de définir des minuteries, d'envoyer et de recevoir des messages aux clients sur le processeur d'applications, de journaliser, etc. Pour plus de détails, consultez les en-têtes de l'API .
En plus des fonctionnalités de base du système codifiées dans l'API CHRE, il existe également des fonctionnalités obligatoires au niveau du système CHRE spécifiées au niveau Context Hub HAL. Le plus important d’entre eux est la possibilité de charger et décharger dynamiquement des nanoapplications.
Bibliothèque standard C/C++
Pour minimiser l'utilisation de la mémoire et la complexité du système, les implémentations CHRE doivent prendre en charge uniquement un sous-ensemble des bibliothèques standard C et C++ et des fonctionnalités de langage nécessitant la prise en charge de l'exécution. Suivant ces principes, certaines fonctionnalités sont explicitement exclues en raison de leur mémoire et/ou de leurs dépendances étendues au niveau du système d'exploitation, et d'autres parce qu'elles sont supplantées par des API spécifiques à CHRE plus adaptées. Bien qu'il ne s'agisse pas d'une liste exhaustive, les fonctionnalités suivantes ne sont pas destinées à être mises à la disposition des nanoapplications :
- Exceptions C++ et informations sur le type d'exécution (RTTI)
- Prise en charge du multithreading de bibliothèque standard, y compris les en-têtes C++ 11
<thread>,<mutex>,<atomic>,<future> - Bibliothèques d'entrée/sortie standard C et C++
- Bibliothèque de modèles standard C++ (STL)
- Bibliothèque d'expressions régulières standard C++
- Allocation dynamique de mémoire via des fonctions standard (par exemple,
malloc,calloc,realloc,free,operator new) et d'autres fonctions de bibliothèque standard qui utilisent intrinsèquement l'allocation dynamique, telles questd::unique_ptr - Prise en charge de la localisation et des caractères Unicode
- Bibliothèques de dates et d'heures
- Fonctions qui modifient le déroulement normal du programme, notamment
<setjmp.h>,<signal.h>,abort,std::terminate - Accès à l'environnement hôte, y compris
system,getenv - POSIX et autres bibliothèques non incluses dans les standards de langage C99 ou C++11
Dans de nombreux cas, des fonctionnalités équivalentes sont disponibles à partir des fonctions API CHRE et/ou des bibliothèques d'utilitaires. Par exemple, chreLog peut être utilisé pour la journalisation de débogage ciblée sur le système Android logcat, où un programme plus traditionnel pourrait utiliser printf ou std::cout .
En revanche, certaines fonctionnalités de bibliothèque standard sont requises. Il appartient à l'implémentation de la plate-forme de les exposer via des bibliothèques statiques pour inclusion dans un binaire nanoapp, ou par liaison dynamique entre la nanoapp et le système. Cela comprend, sans toutefois s'y limiter :
- Utilitaires de chaîne/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,remainderf - Fonctions exponentielles/puissance :
expf,log2f,powf,sqrtf - Fonctions trigonométriques/hyperboliques :
sinf,cosf,tanf,asinf,acosf,atan2f,tanhf
- Opérations de base :
Bien que certaines plates-formes sous-jacentes prennent en charge des fonctionnalités supplémentaires, une nanoapp n'est pas considérée comme portable dans les implémentations CHRE à moins qu'elle ne limite ses dépendances externes aux fonctions de l'API CHRE et aux fonctions de bibliothèque standard approuvées.
Caractéristiques optionnelles
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 ne soient peut-être pas nécessaires pour prendre en charge une implémentation CHRE compatible, elles peuvent être nécessaires pour prendre en charge une nanoapplication particulière. Même si une plate-forme ne prend pas en charge un ensemble donné d'API, les nanoapplications qui font référence à ces fonctions doivent pouvoir être créées et chargées.
Capteurs
L'API CHRE offre la possibilité de demander des données à des capteurs, notamment un accéléromètre, un gyroscope, un magnétomètre, un capteur de lumière ambiante et un capteur de proximité. Ces API sont destinées à fournir un ensemble de fonctionnalités similaires aux API des capteurs Android, notamment la prise en charge du regroupement d'échantillons de capteurs afin de réduire la consommation d'énergie. Le traitement des données des capteurs au sein de CHRE permet un traitement de puissance et de latence beaucoup plus faible des signaux de mouvement par rapport à l'exécution sur le point d'accès.
GNSS
CHRE fournit des API pour demander des données de localisation à un système mondial de navigation par satellite (GNSS), y compris le GPS et d'autres constellations de satellites. Cela inclut les demandes de relevés de position périodiques, ainsi que les données de mesure brutes, bien que les deux soient des capacités indépendantes. Comme CHRE a un lien direct avec le sous-système GNSS, la puissance est réduite par rapport aux requêtes GNSS basées sur AP, car l'AP peut rester endormi pendant tout le cycle de vie d'une session de localisation.
Wifi
CHRE offre la possibilité d'interagir avec la puce Wi-Fi, principalement à des fins de localisation. Bien que le GNSS fonctionne bien pour les emplacements extérieurs, les résultats des analyses Wi-Fi peuvent fournir des informations de localisation précises à l'intérieur et dans les zones développées. En plus d'éviter le coût de réveil du point d'accès pour une analyse, CHRE peut écouter les résultats des analyses Wi-Fi effectuées par le micrologiciel Wi-Fi à 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 permet de réduire le nombre total d'analyses Wi-Fi effectuées, économisant ainsi de l'énergie.
La prise en charge du Wi-Fi a été ajoutée dans l'API CHRE v1.1, y compris la possibilité de surveiller les résultats d'analyse et de déclencher des analyses à la demande. Ces fonctionnalités ont été étendues dans la version 1.2 avec la possibilité d'effectuer des mesures de temps d'aller-retour (RTT) sur des points d'accès prenant en charge cette fonctionnalité, ce qui permet une détermination précise de la position relative.
WWAN
L'API CHRE offre la possibilité de récupérer des informations d'identification de cellule pour la cellule de desserte et ses voisines, qui sont généralement utilisées à des fins de localisation à gros grain.
l'audio
CHRE peut traiter des lots de données audio provenant d'un microphone de faible consommation, qui exploite généralement le matériel utilisé pour implémenter SoundTrigger HAL. Le traitement des données audio dans CHRE peut permettre de les fusionner avec d'autres données, telles que des capteurs de mouvement.
Implémentation de référence
Le code de référence pour le framework CHRE est inclus dans AOSP dans le projet system/chre , implémenté en C++11. Bien que cela ne soit pas strictement obligatoire, il est recommandé que toutes les implémentations de CHRE soient basées sur cette base de code, afin de garantir la cohérence et d'accélérer l'adoption de nouvelles fonctionnalités. Ce code peut être considéré comme un analogue du framework Android de base dans la mesure où il s'agit d'une implémentation open source d'API utilisées par les applications, servant de référence et de norme de compatibilité. Bien qu'il puisse être personnalisé et étendu avec des fonctionnalités spécifiques au fournisseur, il est recommandé de conserver le code commun aussi proche que possible de la référence. Semblable aux HAL d'Android, l'implémentation de référence CHRE utilise diverses abstractions de plateforme pour lui permettre de s'adapter à tout appareil répondant aux exigences minimales.
Pour plus de détails techniques et un guide de portage, consultez le README inclus dans le projet system/chre .