Les smartphones contiennent plusieurs processeurs, chacun étant optimisé pour effectuer différentes tâches. Toutefois, Android ne s'exécute que sur un seul processeur : le processeur d'applications (AP). Le processeur d'application est conçu pour offrir d'excellentes performances dans les cas d'utilisation avec écran allumé, comme les jeux. Cependant, il consomme trop d'énergie pour prendre en charge les fonctionnalités qui nécessitent des traitements fréquents et brefs 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 accomplissant leurs tâches sans impacter de manière significative 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 Context Hub (CHRE) fournit une plate-forme commune pour exécuter des applications sur un processeur basse consommation, avec une API simple, standardisée et adaptée aux systèmes embarqués. Le CHRE permet aux OEM d'appareils et à leurs partenaires de confiance de décharger le traitement du processeur d'application, afin d'économiser la batterie et d'améliorer divers aspects de l'expérience utilisateur. Il permet également une classe de fonctionnalités toujours activées et contextuelles, en particulier celles impliquant l'application du machine learning à la détection ambiante.
Concepts clés
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 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 nano-applications sont presque toujours liées à une ou plusieurs applications clientes s'exécutant dans Android, qui interagissent avec CHRE et les nano-applications via des API système ContextHubManager à accès restreint.
De manière générale, des parallèles peuvent être établis entre l'architecture de CHRE et celle d'Android dans son ensemble. Toutefois, il existe quelques différences importantes :
- CHRE n'est compatible qu'avec les 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 CHRE, CHRE lui-même ne fournit pas les fonctionnalités de capteur requises par la HAL des capteurs Android. CHRE est lié au HAL du hub de contexte et agit en tant que client d'un framework de capteur spécifique à l'appareil pour recevoir les données du capteur sans impliquer l'AP.
Figure 1 : Architecture du framework CHRE
HAL du hub contextuel
La couche d'abstraction matérielle (HAL) du Context Hub est l'interface entre le framework Android et l'implémentation CHRE de l'appareil, définie dans hardware/interfaces/contexthub.
La HAL Context Hub définit les API par lesquelles le framework Android découvre les hubs de contexte disponibles et leurs nano-applications, interagit avec ces nano-applications par le biais du transfert de messages et permet le chargement et le déchargement des nano-applications. Une implémentation de référence de la HAL Context Hub fonctionnant 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, c'est la définition HAL qui prévaut.
Initialisation
Au démarrage d'Android, 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 et 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 de CHRE. Ces applications sont appelées "nano-applications préchargées" et doivent être incluses dans la première réponse possible à queryApps().
Le HAL du hub de contexte permet également de charger et de décharger des nano-applications de manière dynamique au moment de l'exécution, grâce aux 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 pour charger une nano-application implique de l'écrire dans une mémoire non volatile, telle qu'une mémoire flash attachée au processeur qui exécute CHRE, l'implémentation CHRE doit toujours démarrer avec ces nano-applications dynamiques à l'état désactivé. Cela signifie qu'aucune partie du code de la nano-application n'est exécutée tant qu'une requête enableNanoapp() n'est pas reçue via la 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 en cours de 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. La HAL en informe Android via l'événement RESTARTED, qu'elle ne doit envoyer qu'après la réinitialisation de CHRE au point où il peut 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, où l'unité de calcul principale est un événement transmis au point d'entrée de 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 nano-application donnée via l'un des trois points d'entrée de la nano-application (nanoappStart(), nanoappHandleEvent() et nanoappEnd()) ou via un rappel fourni dans un appel d'API CHRE précédent. Les nano-applications 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 outils permettant d'accéder aux signaux contextuels, y compris les capteurs, GNSS, Wi-Fi, WWAN et audio. Elle peut être étendue avec des fonctionnalités supplémentaires spécifiques au fournisseur pour être utilisée par des nano-applications spécifiques au fournisseur.
Système de compilation
Bien que le HAL Context Hub et d'autres composants AP nécessaires soient intégrés à Android, le code qui s'exécute dans 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 les nano-applications 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 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 restreint de C++11 adapté aux applications aux ressources limitées.
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 avec tous les appareils compatibles avec CHRE. Cela signifie que le code source d'une nano-application n'a pas besoin d'être modifié pour être compatible avec un nouveau type d'appareil, mais il peut être nécessaire de le recompiler spécifiquement pour l'ensemble d'instructions du processeur ou l'interface binaire d'application (ABI) de l'appareil cible. L'architecture CHRE et la conception de l'API garantissent également que les nano-applications sont binaires compatibles avec différentes versions de l'API CHRE. Cela signifie qu'une nano-application 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 pour laquelle la nano-application est compilée. En d'autres termes, si un binaire de nanoapp s'exécute sur un appareil compatible avec l'API CHRE v1.3 et que cet appareil est mis à niveau pour être compatible avec l'API CHRE v1.4, le même binaire de nanoapp continue de fonctionner. De même, la nano-application peut s'exécuter sur l'API CHRE v1.2 et peut déterminer au moment de l'exécution si elle nécessite des fonctionnalités de l'API v1.3 pour atteindre son utilisation, ou si elle peut fonctionner, potentiellement avec une dégradation progressive des fonctionnalités.
De nouvelles versions de l'API CHRE sont publiées en même temps qu'Android. Toutefois, comme l'implémentation CHRE fait partie de l'implémentation du fournisseur, la version de l'API CHRE compatible avec 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 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 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 apportées à 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)
Ajout de fonctionnalités de localisation via la localisation GNSS et les mesures brutes, la recherche 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 distance Wi-Fi RTT, des notifications de réveil et de veille du point d'accès, et d'autres améliorations.
Version 1.3 (Android 10)
Améliore les fonctionnalités liées aux données de calibration des capteurs, ajoute la prise en charge du vidage des données de capteur par lot à 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 vidage de débogage des nano-applications 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 dans toutes les implémentations 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 informations, etc. Pour en savoir plus, consultez En-têtes d'API.
En plus des fonctionnalités système de base codifiées dans l'API CHRE, il existe également des fonctionnalités obligatoires au niveau du système CHRE spécifiées au niveau de la couche 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 minimiser l'utilisation de la mémoire et la complexité du système, les implémentations CHRE ne sont tenues de prendre en charge qu'un sous-ensemble des bibliothèques et des fonctionnalités de langage C et C++ standards nécessitant une assistance d'exécution. En suivant ces principes, certaines fonctionnalités sont explicitement exclues en raison de leur mémoire et de leurs nombreuses dépendances au niveau de l'OS, et d'autres parce qu'elles sont remplacées par des API CHRE plus adaptées. Bien que cette liste ne soit pas exhaustive, les fonctionnalités suivantes ne sont pas destinées à être mises à la disposition des nano-applications :
- Exceptions C++ et informations de type d'exécution (RTTI)
- Compatibilité avec le multithreading de la 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 standards (STL) 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ès à l'environnement hôte, y compris
system,getenv - Bibliothèques 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 utilitaires. Par exemple, chreLog peut être utilisé pour la journalisation de débogage ciblant le système logcat Android, alors qu'un programme plus traditionnel pourrait utiliser printf ou std::cout.
En revanche, certaines fonctionnalités de la 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 fichier binaire de nano-appli, ou par liaison dynamique entre la nano-appli et le système. Cela inclut, sans s'y limiter, les éléments suivants :
- Utilitaires de chaînes et de tableaux :
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 de puissance :
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 soient compatibles avec des fonctionnalités supplémentaires, une nano-application n'est pas considérée comme portable sur les implémentations CHRE, sauf si elle limite ses dépendances externes aux fonctions de l'API CHRE et aux fonctions de la 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 forcément nécessaires 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 ne prend pas en charge un ensemble donné d'API, les nano-applications qui référencent ces fonctions doivent pouvoir être créé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 le capteur de proximité. Ces API sont destinées à fournir un ensemble de fonctionnalités semblables à celles des API Android Sensors, 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 de capteurs dans le CHRE permet un traitement des signaux de mouvement beaucoup moins gourmand en énergie et avec une latence plus faible que sur le processeur d'application.
GNSS
CHRE fournit des API permettant de 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 corrections de position périodiques, ainsi que les données de mesure brutes, bien que les deux soient des fonctionnalités indépendantes. Comme le CHRE est directement lié au sous-système GNSS, la consommation d'énergie est réduite par rapport aux requêtes GNSS basées sur l'AP, car l'AP peut rester en veille pendant toute la durée de vie d'une session de localisation.
Wi-Fi
CHRE permet 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 l'activation du PA 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 transmis au PA 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 à 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 du délai aller-retour (RTT) par rapport aux points d'accès compatibles avec la fonctionnalité, ce qui permet de déterminer précisément la position relative.
WWAN
L'API CHRE permet de récupérer des informations d'identification des cellules pour la cellule de desserte et ses voisines, qui sont généralement utilisées à des fins de localisation approximative.
Audio
CHRE peut traiter des lots de données audio provenant d'un micro basse consommation, qui utilise généralement le matériel servant à 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 les 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, nous recommandons que toutes les implémentations CHRE soient basées sur ce code source, 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, car il s'agit d'une implémentation Open Source des API utilisées par les applications, servant de référence et de norme pour la compatibilité. Bien qu'il puisse être personnalisé et étendu avec des fonctionnalités spécifiques au fournisseur, il est recommandé de maintenir 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 diverses abstractions de plate-forme pour pouvoir être adaptée à n'importe quel appareil répondant à la configuration minimale requise.
Pour obtenir des informations techniques et un guide de portage, consultez le fichier README inclus dans le projet system/chre.