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. Les flux de contrôle proviennent des applications et sont envoyés aux capteurs, tandis que les flux de données proviennent des capteurs et sont envoyés aux applications.
Figure 1 : Couches de la pile de capteurs Android et leurs propriétaires respectifs
SDK
Les applications accèdent aux capteurs via l'API Sensors SDK (kit de développement logiciel). 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, en demandant des événements à 100 Hz et en autorisant les événements à être signalés avec une latence d'une seconde.
- L'application recevra les événements de l'accéléromètre à une fréquence d'au moins 100 Hz, avec un éventuel retard d'une seconde maximum.
Pour en savoir plus sur le SDK, consultez la documentation pour les développeurs.
Framework
Le framework est chargé de relier les différentes applications au HAL. Le HAL lui-même est à client unique. Sans ce multiplexage au niveau du framework, une seule application pourrait accéder à chaque capteur à un moment donné.
- Lorsqu'une première application s'enregistre auprès d'un capteur, le framework envoie une requête au HAL pour activer le capteur.
- Lorsque des applications supplémentaires s'enregistrent auprès du même capteur, le framework prend en compte les exigences de chaque application et envoie les paramètres demandés mis à jour au HAL.
- La fréquence d'échantillonnage sera la fréquence d'échantillonnage maximale demandée. 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 sera la plus faible de celles demandées. Si une application demande un capteur avec une latence de rapport 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 rapport maximale non nulle. Pour en savoir plus, consultez Traitement par lot.
- Lorsque la dernière application enregistrée auprès d'un capteur se désinscrit, les frameworks envoient une requête au HAL pour désactiver le capteur afin d'éviter toute consommation d'énergie inutile.
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'arriveront pas à un rythme plus rapide. Si une autre application a demandé le même capteur à une fréquence plus élevée, la première application les recevra également à la fréquence rapide.
- Le même manque de garantie s'applique à la latence maximale demandée pour les rapports : les applications peuvent recevoir des événements avec une latence bien inférieure à celle demandée.
- En dehors de la fréquence d'échantillonnage et de la latence maximale des rapports, les applications ne peuvent pas configurer les paramètres des capteurs.
- Par exemple, imaginez un capteur physique qui peut fonctionner en mode "haute précision" et en mode "faible consommation d'énergie".
- Un seul 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 le mode basse consommation. Le framework ne pourrait pas satisfaire les deux applications. Le framework doit toujours être en mesure de satisfaire tous ses clients. Cette option n'est donc pas envisageable.
- 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 vecteur de rotation, gravité et 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 d'autres implémentations ont accès. De plus, elle doit s'exécuter sur le SoC. Elle n'est donc pas aussi précise ni aussi économe en énergie que d'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 les 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 plus maintenue et peut entraîner l'échec du CTS pour les appareils qui en dépendent.
Détails techniques
Cette section fournit des informations générales aux personnes qui gèrent le code du framework Android Open Source Project (AOSP). Elle n'est pas pertinente 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 niveau inférieur pour accéder 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 Binder IPC pour accéder aux services spécifiques aux capteurs.
Binder IPC
Les proxys Binder IPC facilitent la communication au-delà des limites des processus.
HAL
L'API Sensors Hardware Abstraction Layer (HAL) 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 la fonctionnalité est liée à ces versions.
Le framework Android est actuellement compatible avec les versions 1.0 et 1.3, mais la version 1.0 ne le sera bientôt plus. Cette documentation décrit le comportement de la version 1.3, vers laquelle tous les appareils doivent être mis à niveau. Pour savoir comment passer à la version 1.3, consultez Obsolescence de la version HAL.
Pilote du noyau
Les pilotes de capteur interagissent avec les appareils physiques. Dans certains cas, l'implémentation 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 capteur de fournir les pilotes, mais c'est lui qui écrit l'implémentation HAL.
Dans tous les cas, l'implémentation HAL et les pilotes du noyau relèvent de la responsabilité des fabricants de matériel, et Android ne fournit pas d'approche privilégiée 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 puissance lorsque le SoC peut être en mode veille. Par exemple, le comptage de pas ou la fusion de capteurs peuvent être effectués 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 de capteur. Pour en savoir plus, consultez la section Traitement par lot.
Remarque : Pour développer de nouvelles fonctionnalités ContextHub qui utilisent de nouveaux capteurs ou de nouvelles LED, vous pouvez également utiliser un Neonkey SensorHub connecté à une carte de développement Hikey ou Hikey960.
La manière 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 dans 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 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 le calcul générique et des accélérateurs matériels pour permettre un calcul à très faible consommation d'énergie pour les capteurs à faible consommation d'énergie.
L'architecture du hub de capteurs et sa communication avec les capteurs et le SoC (bus I2C, bus SPI, etc.) ne sont pas spécifiées par Android, mais elles doivent viser à minimiser 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 : une pour les interruptions de réveil (pour les capteurs de réveil) et l'autre pour les interruptions de non-réveil (pour les capteurs de non-réveil).
Capteurs
Il s'agit des puces MEMS physiques qui effectuent les mesures. Dans de nombreux cas, plusieurs capteurs physiques sont présents sur la même puce. Par exemple, certaines puces incluent un accéléromètre, un gyroscope et un magnétomètre. (Ces puces sont souvent appelées puces à neuf axes, car chaque capteur fournit des données sur trois axes.)
Certaines 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 sur neuf axes.
Bien que les exigences et recommandations de puissance et de précision du 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 du vecteur de rotation du jeu a des implications sur la précision requise pour le gyroscope physique. Il incombe au fabricant de l'appareil de définir les exigences relatives aux capteurs physiques.