La figure ci-dessous représente la pile de capteurs Android. Chaque composant ne communique qu'avec les composants situés directement au-dessus et en dessous de lui, bien que certains capteurs puissent contourner le hub de capteurs lorsqu'il est présent. Le contrôle circule des applications vers les capteurs, et les données circulent des capteurs vers les applications.
Figure 1 : Couches de la pile de capteurs Android et propriétaires respectifs
SDK
Les applications accèdent aux capteurs via l'API du SDK (Software Development Kit) Sensors. Le SDK contient des fonctions permettant de lister les capteurs disponibles et de s'enregistrer auprès d'un capteur.
Lors de l'enregistrement auprès d'un capteur, l'application spécifie sa fréquence d'échantillonnage préférée et ses exigences de latence.
- Par exemple, une application peut s'enregistrer auprès de l'accéléromètre par défaut, demander des événements à 100 Hz et autoriser les événements à être signalés avec une latence de 1 seconde.
- L'application recevra des événements de l'accéléromètre à une fréquence d'au moins 100 Hz, avec un délai pouvant aller jusqu'à une seconde.
Pour en savoir plus sur le SDK, consultez la documentation pour les développeurs.
Framework
Le framework est chargé de lier les différentes applications au HAL. Le HAL lui-même est à un seul client. Sans ce multiplexage au niveau du framework, une seule application pourrait accéder à chaque capteur à un moment donné.
- Lorsqu'une première application s'inscrit auprès d'un capteur, le framework envoie une requête au HAL pour activer le capteur.
- Lorsque des applications supplémentaires s'inscrivent au même capteur, le framework tient compte des exigences de chaque application et envoie les paramètres demandés mis à jour au HAL.
- La fréquence d'échantillonnage correspond au maximum des fréquences d'échantillonnage demandées. Cela signifie que certaines applications recevront des événements à une fréquence supérieure à celle qu'elles ont demandée.
- La latence maximale des rapports correspond à la valeur minimale de celles demandées. Si une application demande un capteur avec une latence de signalement maximale de 0, toutes les applications recevront les événements de ce capteur en mode continu, même si certaines ont demandé le capteur avec une latence de signalement maximale non nulle. Pour en savoir plus, consultez Grouper les requêtes.
- Lorsque la dernière application enregistrée sur un capteur s'en désinscrit, les frameworks envoient une requête au HAL pour désactiver le capteur afin que l'alimentation ne soit pas consommée inutilement.
Impact du multiplexage
Ce besoin d'une couche de multiplexage dans le framework explique certaines décisions de conception.
- Lorsqu'une application demande une fréquence d'échantillonnage spécifique, il n'est pas garanti que les événements n'arrivent pas à un rythme plus rapide. Si une autre application a demandé le même capteur à un débit plus élevé, la première application le recevra également à ce débit.
- Le même manque de garantie s'applique à la latence maximale de création de rapports demandée : les applications peuvent recevoir des événements avec une latence beaucoup plus faible que celle demandée.
- En dehors de la fréquence d'échantillonnage et de la latence de création de rapports maximale, les applications ne peuvent pas configurer les paramètres des capteurs.
- Par exemple, imaginez un capteur physique pouvant fonctionner à la fois en mode "haute précision" et en mode "faible consommation d'énergie".
- Seul l'un de ces deux modes peut être utilisé sur un appareil Android, car sinon, une application pourrait demander le mode haute précision et une autre un mode basse consommation. Le framework ne pourrait pas satisfaire les deux applications. Le framework doit toujours être en mesure de satisfaire tous ses clients. Ce n'est donc pas une option.
- Il n'existe aucun mécanisme permettant d'envoyer des données des applications aux capteurs ou à leurs pilotes. Cela garantit qu'une application ne peut pas modifier le comportement des capteurs, ce qui pourrait perturber d'autres applications.
Fusion de capteurs
Le framework Android fournit une implémentation par défaut pour certains capteurs composites. Lorsqu'un gyroscope, un accéléromètre et un magnétomètre sont présents sur un appareil, mais qu'aucun capteur de vecteur de rotation, de gravité et d'accélération linéaire n'est présent, le framework implémente ces capteurs afin que les applications puissent toujours les utiliser.
L'implémentation par défaut n'a pas accès à toutes les données auxquelles les autres implémentations ont accès, et elle doit s'exécuter sur le SoC. Elle n'est donc pas aussi précise ni aussi économe en énergie que les autres implémentations. Dans la mesure du possible, les fabricants d'appareils doivent définir leurs propres capteurs fusionnés (vecteur de rotation, gravité et accélération linéaire, ainsi que de nouveaux capteurs composites tels que le vecteur de rotation du jeu) plutôt que de s'appuyer sur cette implémentation par défaut. Les fabricants d'appareils peuvent également demander aux fournisseurs de puces de capteurs de leur fournir une implémentation.
L'implémentation par défaut de la fusion de capteurs n'est pas gérée et peut entraîner l'échec de la certification CTS des appareils qui s'y appuient.
Détails techniques
Cette section fournit des informations générales pour les personnes qui gèrent le code du framework Android Open Source Project (AOSP). Il n'est pas pertinent pour les fabricants de matériel.
JNI
Le framework utilise une interface Java Native Interface (JNI) associée à android.hardware et située dans le répertoire frameworks/base/core/jni/. Ce code appelle le code natif de bas niveau pour obtenir l'accès au matériel du capteur.
Framework natif
Le framework natif est défini dans frameworks/native/ et fournit un équivalent natif au package android.hardware. Le framework natif appelle les proxys IPC Binder pour obtenir l'accès aux services spécifiques aux capteurs.
IPC de classeur
Les proxys IPC du Binder facilitent la communication au-delà des limites de processus.
HAL
L'API HAL (Hardware Abstraction Layer) des capteurs est l'interface entre les pilotes matériels et le framework Android. Il se compose d'une interface HAL sensors.h et d'une implémentation HAL que nous appelons sensors.cpp.
L'interface est définie par les contributeurs Android et AOSP, et l'implémentation est fournie par le fabricant de l'appareil.
L'interface HAL du capteur se trouve dans hardware/libhardware/include/hardware.
Pour en savoir plus, consultez sensors.h.
Cycle de publication
L'implémentation HAL spécifie la version de l'interface HAL qu'elle implémente en définissant your_poll_device.common.version. Les versions d'interface HAL existantes sont définies dans sensors.h, et les fonctionnalités sont liées à ces versions.
Le framework Android est actuellement compatible avec les versions 1.0 et 1.3, mais la version 1.0 ne sera bientôt plus prise en charge. Cette documentation décrit le comportement de la version 1.3, vers laquelle tous les appareils doivent passer. Pour savoir comment passer à la version 1.3, consultez la section Abandon de la version HAL.
Pilote de kernel
Les pilotes de capteurs interagissent avec les appareils physiques. Dans certains cas, l'implémentation du HAL et les pilotes sont la même entité logicielle. Dans d'autres cas, l'intégrateur matériel demande aux fabricants de puces de capteurs de fournir les pilotes, mais ce sont eux qui écrivent l'implémentation du HAL.
Dans tous les cas, l'implémentation du HAL et les pilotes du noyau sont de la responsabilité des fabricants de matériel, et Android ne fournit pas d'approches privilégiées pour les écrire.
Hub de capteurs
La pile de capteurs d'un appareil peut éventuellement inclure un hub de capteurs, utile pour effectuer des calculs de bas niveau à faible consommation d'énergie lorsque le SoC peut être en mode suspension. Par exemple, le comptage des pas ou la fusion de capteurs peut être effectué sur ces puces. C'est également un bon endroit pour implémenter le traitement par lot des capteurs, en ajoutant des FIFO matériels pour les événements des capteurs. Pour en savoir plus, consultez la section Groupement.
Remarque:Pour développer de nouvelles fonctionnalités ContextHub qui utilisent de nouveaux capteurs ou LED, vous pouvez également utiliser un SensorHub Neonkey connecté à une carte de développement Hikey ou Hikey960.
La façon dont le hub de capteurs est matérialisé dépend de l'architecture. Il s'agit parfois d'une puce distincte, et parfois d'une puce incluse sur la même puce que le SoC. Les caractéristiques importantes du hub de capteurs sont qu'il doit contenir suffisamment de mémoire pour le traitement par lot et qu'il doit consommer très peu d'énergie pour permettre l'implémentation des capteurs Android à faible consommation d'énergie. Certains hubs de capteurs contiennent un microcontrôleur pour les calculs génériques et des accélérateurs matériels pour permettre des calculs à très faible consommation d'énergie pour les capteurs à faible consommation d'énergie.
L'architecture du hub de capteurs et la façon dont il communique avec les capteurs et le SoC (bus I2C, bus SPI, etc.) ne sont pas spécifiées par Android, mais elles doivent viser à réduire la consommation d'énergie globale.
Une option qui semble avoir un impact significatif sur la simplicité de l'implémentation consiste à avoir deux lignes d'interruption allant du hub de capteurs au SoC : l'une pour les interruptions de réveil (pour les capteurs de réveil) et l'autre pour les interruptions non de réveil (pour les capteurs non de réveil).
Capteurs
Ce sont les puces MEMS physiques qui effectuent les mesures. Dans de nombreux cas, plusieurs capteurs physiques sont présents sur la même puce. Par exemple, certains chips incluent un accéléromètre, un gyroscope et un magnétomètre. (Ces puces sont souvent appelées puces à 9 axes, car chaque capteur fournit des données sur trois axes.)
Certains de ces puces contiennent également une logique permettant d'effectuer des calculs habituels tels que la détection de mouvement, la détection de pas et la fusion de capteurs à 9 axes.
Bien que les exigences et recommandations de puissance et de précision de la CDD ciblent le capteur Android et non les capteurs physiques, ces exigences ont un impact sur le choix des capteurs physiques. Par exemple, l'exigence de précision sur le vecteur de rotation du jeu a des conséquences sur la précision requise pour le gyroscope physique. C'est au fabricant de l'appareil de déduire les exigences concernant les capteurs physiques.