La figure ci-dessous représente la pile de capteurs Android. Chaque composant communique uniquement avec les composants situés directement au-dessus et en dessous, bien que certains capteurs puissent contourner le concentrateur de capteurs lorsqu'il est présent. Les flux de contrôle des applications vers les capteurs et les flux de données des capteurs vers les 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 (Software Development Kit) . Le SDK contient des fonctions permettant de répertorier les capteurs disponibles et de s'enregistrer auprès d'un capteur.
Lors de l'enregistrement sur 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 le signalement des événements avec une latence d'une seconde.
- L'application recevra des événements de l'accéléromètre à une fréquence d'au moins 100 Hz, et éventuellement retardée jusqu'à 1 seconde.
Consultez la documentation du développeur pour plus d'informations sur le SDK.
Cadre
Le framework est chargé de relier les différentes applications à HAL . Le HAL lui-même est mono-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'enregistre auprès d'un capteur, le framework envoie une demande à la HAL pour activer le capteur.
- Lorsque des applications supplémentaires s'enregistrent sur le même capteur, le framework prend en compte les exigences de chaque application et envoie les paramètres demandés mis à jour à HAL.
- La fréquence d'échantillonnage sera le maximum des fréquences d'échantillonnage demandées, ce qui signifie que certaines applications recevront des événements à une fréquence supérieure à celle qu'elles ont demandée.
- La latence de rapport maximale 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. Voir Regroupement pour plus de détails.
- Lorsque la dernière application enregistrée auprès d'un capteur se désenregistre de celui-ci, les frameworks envoient une demande à HAL pour désactiver le capteur afin que l'énergie 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, rien ne garantit que les événements n'arriveront pas à un rythme plus rapide. Si une autre application a demandé le même capteur à un rythme plus rapide, la première application les recevra également au rythme rapide.
- La même absence de garantie s'applique à la latence de rapport maximale demandée : les applications peuvent recevoir des événements avec une latence bien inférieure à celle demandée.
- Outre la fréquence d'échantillonnage et la latence maximale des rapports, les applications ne peuvent pas configurer les paramètres du capteur.
- Par exemple, imaginez un capteur physique qui peut fonctionner à la fois en mode "haute précision" et "basse consommation".
- 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 un mode basse consommation ; il n'y aurait aucun moyen pour le cadre de satisfaire les deux applications. Le framework doit toujours pouvoir satisfaire tous ses clients, ce n'est donc pas une option.
- Il n'y a aucun mécanisme pour envoyer des données des applications aux capteurs ou à leurs pilotes. Cela garantit qu'une application ne peut pas modifier le comportement des capteurs, interrompant ainsi les 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 d'autres implémentations. Autant que 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 des capteurs composites plus récents comme le vecteur de rotation du jeu ) plutôt que de se fier à cette implémentation par défaut. Les fabricants d'appareils peuvent également demander aux fournisseurs de puces de capteur de leur fournir une implémentation.
L'implémentation par défaut de la fusion de capteurs n'est pas maintenue et peut entraîner l'échec du CTS des périphériques qui en dépendent.
Sous la capuche
Cette section est fournie à titre d'information de base pour ceux qui maintiennent le code de cadre Android Open Source Project (AOSP). Il n'est pas pertinent pour les fabricants de matériel.
JNI
Le framework utilise une 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 obtenir l'accès au matériel du capteur.
Cadre 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 obtenir l'accès aux services spécifiques aux capteurs.
Classeur CIB
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 assurée par le fabricant de l'appareil.
L'interface HAL du capteur se trouve dans hardware/libhardware/include/hardware . Voir capteurs.h pour plus de détails.
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 prend actuellement en charge les versions 1.0 et 1.3, mais la 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 être mis à niveau. Pour plus de détails sur la mise à niveau vers la version 1.3, consultez Obsolescence de la version HAL .
Pilote du noyau
Les pilotes de capteur interagissent avec les périphériques 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 ce sont eux qui écrivent l'implémentation HAL.
Dans tous les cas, l'implémentation de HAL et les pilotes du noyau relèvent de la responsabilité des fabricants de matériel, et Android ne fournit pas d'approches préférées pour les écrire.
Moyeu de capteur
La pile de capteurs d'un appareil peut éventuellement inclure un concentrateur de capteurs, utile pour effectuer des calculs de bas niveau à faible puissance tandis que 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 regroupement de capteurs, en ajoutant des FIFO matériels pour les événements de capteur. Voir Regroupement pour plus d'informations.
Remarque : Pour développer de nouvelles fonctionnalités ContextHub qui utilisent de nouveaux capteurs ou LED, vous pouvez également utiliser un Neonkey SensorHub connecté à une carte de développement Hikey ou Hikey960.
La matérialisation du concentrateur de capteurs dépend de l'architecture. Il s'agit parfois d'une puce séparée, et parfois incluse sur la même puce que le SoC. Les caractéristiques importantes du concentrateur de capteurs sont qu'il doit contenir suffisamment de mémoire pour le traitement par lots et consommer très peu d'énergie pour permettre la mise en œuvre des capteurs Android à faible consommation. Certains concentrateurs 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 puissance pour les capteurs à faible puissance.
La manière dont le concentrateur de capteurs est architecturé et comment il communique avec les capteurs et le SoC (bus I2C, bus SPI, …) n'est pas spécifiée par Android, mais il devrait viser à minimiser la consommation d'énergie globale.
Une option qui semble avoir un impact significatif sur la simplicité de mise en œuvre consiste à avoir deux lignes d'interruption allant du concentrateur de capteurs au SoC : une pour les interruptions de réveil (pour les capteurs de réveil) et l'autre pour les interruptions sans réveil. (pour les capteurs sans réveil).
Capteurs
Ce sont les puces MEM 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 à 9 axes, car chaque capteur fournit des données sur 3 axes.)
Certaines de ces puces contiennent également une logique pour 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 les recommandations de puissance et de précision 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 implications sur la précision requise pour le gyroscope physique. Il appartient au fabricant de l'appareil de dériver les exigences pour les capteurs physiques.