Les smartphones contiennent un certain nombre de processeurs, chacun optimisé pour effectuer différentes tâches. Cependant, Android ne s'exécute que sur un seul processeur: le processeur d'applications. Le processeur de point d'accès est optimisé pour offrir d'excellentes performances pour les cas d'utilisation avec l'écran allumé, comme les jeux, mais il consomme trop d'énergie pour prendre en charge les fonctionnalités qui nécessitent des rafales de traitement fréquentes et courtes en permanence, même lorsque l'écran est éteint. Les processeurs plus petits sont capables de gérer ces charges de travail plus efficacement, en effectuant leurs tâches sans affecter sensiblement l'autonomie de la batterie. Toutefois, les environnements logiciels de ces processeurs basse consommation sont plus limités et peuvent varier considérablement, ce qui rend le développement multiplate-forme difficile.
L'environnement d'exécution du hub contextuel (CHRE) fournit une plate-forme commune pour exécuter des applications sur un processeur à faible consommation d'énergie, avec une API simple, standardisée et adaptée à l'intégration. La CHRE permet aux OEM d'appareils et à leurs partenaires de confiance de décharger facilement le traitement du point d'accès, d'économiser la batterie et d'améliorer divers aspects de l'expérience utilisateur. Elle permet également d'activer une classe de fonctionnalités toujours activées et sensibles au contexte, en particulier celles impliquant l'application du machine learning à la détection de l'environnement.
Concepts clés
Le CHRE est l'environnement logiciel dans lequel de petites applications natives, appelées nano-applications, 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 l'implémentation correcte des 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 et des abstractions communs au matériel et au logiciel sous-jacents via une série de couches d'abstraction de plate-forme (PAL, Platform Abstraction Layer). Les nano-applications sont presque toujours associées à une ou plusieurs applications clientes exécutées sur Android, qui interagissent avec le CHRE et les nano-applications via des API système ContextHubManager à accès limité.
De manière générale, des parallèles peuvent être établis entre l'architecture de CHRE et Android dans son ensemble. Toutefois, il existe quelques distinctions importantes:
- CHRE n'est compatible qu'avec l'exécution de nano-applications 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 à l'utilisation par des applications Android tierces arbitraires. Seules les applications approuvées par le système peuvent y accéder.
Il est également important de faire la distinction entre 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 hub de capteurs et le CHRE, le CHRE lui-même ne fournit pas les fonctionnalités de capteur requises par le HAL Android Sensors. Le CHRE est lié au HAL du hub de contexte et agit en tant que client d'un framework de capteurs spécifique à l'appareil pour recevoir des données de capteur sans impliquer l'AP.
Figure 1 : Architecture du framework CHRE
HAL du hub contextuel
La couche d'abstraction matérielle (HAL) du hub de contexte est l'interface entre le framework Android et l'implémentation du CHRE de l'appareil, définie à hardware/interfaces/contexthub.
Le HAL du hub contextuel définit les API à travers lesquelles le framework Android détecte les hubs de contexte disponibles et leurs nano-applications, interagit avec ces nano-applications via la transmission de messages, et permet de charger et de décharger des nano-applications. Une implémentation de référence du HAL Context Hub compatible 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 de HAL, la définition de HAL prévaut.
Initialisation
Lorsque l'appareil Android démarre, ContextHubService appelle la fonction HAL getHubs() pour déterminer si des hubs de contexte sont disponibles sur l'appareil. Il s'agit d'un appel unique bloquant. Il doit donc se terminer rapidement pour éviter de retarder le démarrage et renvoyer un résultat précis, car de nouveaux hubs de contexte ne peuvent pas être introduits par la suite.
Charger et décharger des nano-applications
Un hub de contexte peut inclure un ensemble de nano-applications incluses dans l'image de l'appareil et chargées au démarrage du CHRE. Il s'agit de nano-applications préchargées, qui doivent être incluses dans la première réponse possible à queryApps().
Le HAL du hub contextuel permet également de charger et de décharger des nano-applications de manière dynamique au moment de l'exécution, via les fonctions loadNanoApp() et unloadNanoApp(). Les nano-applications sont fournies au HAL dans un format binaire spécifique à l'implémentation matérielle et logicielle du CHRE de l'appareil.
Si l'implémentation du chargement d'une nano-application implique de l'écrire dans une mémoire non volatile, telle qu'une mémoire flash connectée au processeur qui exécute CHRE, l'implémentation de CHRE doit toujours démarrer avec ces nano-applications dynamiques à l'état désactivé. Cela signifie qu'aucun code de nanoapp n'est exécuté tant qu'une requête enableNanoapp() n'est pas reçue via le HAL. Les nano-applications préchargées peuvent s'initialiser à l'état activé.
Redémarrages du hub contextuel
Bien que le CHRE ne soit pas censé redémarrer pendant le fonctionnement normal, il peut être nécessaire de récupérer des 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 ne doit envoyer qu'après la réinitialisation du CHRE au point qu'il peut accepter de nouvelles requêtes, telles que queryApps().
Présentation du système CHRE
Le CHRE est conçu autour d'une architecture basée sur les événements, où l'unité de calcul principale est un événement transmis au point d'entrée de la gestion des événements d'une nano-application. Bien que le framework CHRE puisse être multithread, une nano-application donnée n'est jamais exécutée à partir de plusieurs threads en parallèle. Le framework CHRE interagit avec une nanoapplication donnée via l'un des trois points d'entrée nanoapp (nanoappStart(), nanoappHandleEvent() et nanoappEnd()) ou via un rappel fourni dans un appel d'API CHRE antérieur. 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 installations pour l'accès aux signaux contextuels, y compris des capteurs, GNSS, Wi-Fi, WWAN et audio. Elle peut être étendue avec des fonctionnalités supplémentaires spécifiques au fournisseur pour une utilisation par des nanoapplications spécifiques à un fournisseur.
Système de compilation
Bien que le HAL du hub de contexte et d'autres composants nécessaires côté point d'accès soient compilés avec Android, le code exécuté dans le CHRE peut avoir des exigences qui le rendent incompatible avec le système de compilation 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 compilation 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 la CHRE doivent intégrer la prise en charge du système de compilation 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 limité de C++11 adapté aux applications limitées en ressources.
API CHRE
L'API CHRE est un ensemble de fichiers d'en-tête C qui définissent l'interface logicielle entre une nano-application et le système. Il est conçu pour rendre le code des nano-applications compatible sur tous les appareils compatibles avec le CHRE. Cela signifie que le code source d'une nano-application n'a pas besoin d'être modifié pour prendre en charge un nouveau type d'appareil, mais qu'il peut devoir être recompilé spécifiquement pour l'ensemble d'instructions du processeur ou l'interface binaire d'application (ABI) de l'appareil cible. L'architecture et la conception de l'API CHRE garantissent également que les nano-applications sont compatibles binaires entre les différentes versions de l'API CHRE, ce qui signifie qu'une nano-application n'a pas besoin d'être recompilée pour s'exécuter sur un système implémentant une version différente de l'API CHRE par rapport à l'API cible avec laquelle la nano-application 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 et que cet appareil est mis à niveau pour prendre en charge la version 1.4 de l'API CHRE, le même binaire nanoapp continue de fonctionner. De même, nanoapp peut s'exécuter sur l'API CHRE v1.2 et peut déterminer au moment de l'exécution si elle a besoin des capacités de l'API v1.3 pour atteindre son utilisation, ou si elle peut fonctionner avec une dégradation élégante des fonctionnalités.
De nouvelles versions de l'API CHRE sont publiées avec Android. Toutefois, comme l'implémentation de la CHRE fait partie de l'implémentation du fournisseur, la version de l'API CHRE compatible sur un appareil n'est pas nécessairement liée à une version d'Android.
Résumé de la version
Comme le schéma de gestion des versions HIDL d'Android, l'API CHRE suit la gestion sémantique des versions.
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 inclut des annotations de code source pour identifier la version qui a introduit une fonction ou un paramètre, par exemple @since v1.1.
L'implémentation de la 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 nano-applications, telles que les événements et les minuteurs.
Version 1.1 (Android 8)
Introduit des fonctionnalités de localisation via la position GNSS et les mesures brutes, la numérisation Wi-Fi et les informations sur le réseau mobile, ainsi que des améliorations générales pour permettre la communication entre les nano-applications et d'autres améliorations.
Version 1.2 (Android 9)
Ajout de la prise en charge des données d'un micro basse consommation, de la mesure de la latence RTT Wi-Fi, des notifications de réveil et de mise en veille de l'AP, et d'autres améliorations.
Version 1.3 (Android 10)
Améliore les fonctionnalités liées aux données de calibrage des capteurs, ajoute la prise en charge de l'effacement des données de capteur groupées à la demande, définit 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, du dump de débogage de la nano-application et d'autres améliorations.
Fonctionnalités système obligatoires
Bien que les sources de signaux contextuels, comme les capteurs, soient classées dans des zones de fonctionnalités facultatives, quelques fonctions de base sont requises pour toutes les implémentations de CHRE. Cela inclut les API système de base, telles que celles permettant de définir des minuteurs, d'envoyer et de recevoir des messages aux clients sur le processeur d'applications, de consigner des journaux, etc. Pour en savoir plus, consultez les en-têtes des API.
En plus des fonctionnalités système de base codifiées dans l'API CHRE, des fonctionnalités obligatoires au niveau du système CHRE sont également spécifiées au niveau du HAL du hub de contexte. La plus importante d'entre elles est la possibilité de charger et de décharger dynamiquement des nano-applications.
Bibliothèque standard C/C++
Pour réduire l'utilisation de la mémoire et la complexité du système, les implémentations de CHRE ne doivent prendre en charge qu'un sous-ensemble des bibliothèques et des fonctionnalités de langage C et C++ standards nécessitant une prise en charge au moment de l'exécution. Conformément à ces principes, certaines fonctionnalités sont explicitement exclues en raison de leur mémoire et de leurs dépendances étendues au niveau du système d'exploitation, tandis que d'autres sont remplacées par des API spécifiques à CHRE plus adaptées. Bien que cette liste ne soit pas exhaustive, les fonctionnalités suivantes ne sont pas destinées à être disponibles pour les nano-applications:
- Exceptions C++ et informations de type d'exécution (RTTI)
- Prise en charge du multithreading de la bibliothèque standard, y compris les en-têtes C++11
<thread>,<mutex>,<atomic>et<future> - Bibliothèques d'entrée/sortie standards C et C++
- Bibliothèque de modèles standards (STL, Standard Template Library) C++
- Bibliothèque d'expressions régulières standard C++
- Allocation de mémoire dynamique via des fonctions standards (par exemple,
malloc,calloc,realloc,free,operator new) et d'autres fonctions de bibliothèque standards 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 date et d'heure
- Fonctions qui modifient le flux normal du programme, y compris
<setjmp.h>,<signal.h>,abortetstd::terminate - Accéder à l'environnement hôte, y compris
systemetgetenv - POSIX et autres bibliothèques non incluses dans les normes de langage C99 ou C++11
Dans de nombreux cas, des fonctionnalités équivalentes sont disponibles à partir des fonctions de l'API CHRE et des bibliothèques d'utilitaires. Par exemple, chreLog peut être utilisé pour la journalisation de débogage ciblant le système Android Logcat, où un programme plus traditionnel peut utiliser printf ou std::cout.
En revanche, certaines fonctionnalités de la bibliothèque standard sont obligatoires. Il appartient à l'implémentation de la plate-forme de les exposer via des bibliothèques statiques à inclure dans un binaire de nano-application ou via une association dynamique entre la nano-application et le système. 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,remainderf - Fonctions exponentielles et puissances:
expf,log2f,powf,sqrtf - Fonctions trigonométriques et hyperboliques:
sinf,cosf,tanf,asinf,acosf,atan2f,tanhf
- Opérations de base:
Bien que certaines plates-formes sous-jacentes acceptent des fonctionnalités supplémentaires, une nano-application n'est pas considérée comme portable entre les implémentations de CHRE, sauf si elle limite ses dépendances externes aux fonctions de l'API CHRE et aux fonctions de bibliothèque standard approuvées.
Fonctionnalités en option
Pour promouvoir le matériel et les logiciels, l'API CHRE est divisée en zones de fonctionnalités, qui sont considérées comme facultatives du point de vue de l'API. Bien que ces fonctionnalités ne soient pas nécessairement requises pour prendre en charge une implémentation CHRE compatible, elles peuvent l'être pour prendre en charge une nano-application spécifique. Même si une plate-forme n'est pas compatible avec un ensemble donné d'API, les nanoapplications qui y font référence doivent pouvoir être compilées et chargées.
Capteurs
L'API CHRE permet de demander des données à partir de capteurs, y compris l'accéléromètre, le gyroscope, le magnétomètre, le capteur de luminosité ambiante et la proximité. Ces API sont destinées à fournir un ensemble de fonctionnalités semblable à celui des API Android Sensors, y compris la possibilité de regrouper 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 du traitement des signaux de mouvement par rapport à l'exécution sur le point d'accès.
GNSS
Le CHRE fournit des API pour demander des données de localisation à partir d'un système de navigation par satellite global (GNSS), y compris le GPS et d'autres constellations de satellites. Cela inclut les requêtes de corrections de position périodiques, ainsi que les données de mesure brutes, bien que ces deux fonctionnalités soient indépendantes. Comme le point d'accès CHRE dispose d'un lien direct vers le sous-système GNSS, l'alimentation 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 en veille pendant l'ensemble du cycle de vie d'une session de localisation.
Wi-Fi
Le CHRE permet d'interagir avec la puce Wi-Fi, principalement à des fins de localisation. Bien que le GNSS fonctionne bien en extérieur, les résultats des recherches 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 la mise en veille du point d'accès pour une analyse, le 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 envoyés au point d'accès pour des raisons d'alimentation. L'utilisation des analyses de connectivité à des fins contextuelles permet de réduire le nombre total d'analyses Wi-Fi effectuées, ce qui permet d'é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 les résultats des analyses 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 du délai aller-retour (RTT) sur les points d'accès compatibles, ce qui permet de déterminer une position relative précise.
WWAN
L'API CHRE permet de récupérer des informations d'identification de la cellule pour la cellule de service et ses voisins, qui sont généralement utilisées à des fins de localisation à grande échelle.
Audio
Le CHRE peut traiter des lots de données audio à partir d'un micro basse consommation, qui exploite généralement le matériel utilisé pour implémenter le HAL SoundTrigger. 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 du 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 ce codebase, 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 en ce sens qu'il s'agit d'une implémentation Open Source des API utilisées par les applications, qui sert 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, nous vous recommandons de conserver le code commun aussi proche que possible de la référence. Comme les HAL d'Android, l'implémentation de référence CHRE utilise différentes abstractions de plate-forme pour pouvoir être adaptée à tout appareil répondant aux exigences minimales.
Pour en savoir plus sur les détails techniques et obtenir un guide de portage, consultez le fichier README inclus dans le projet system/chre.