La figure ci-dessous représente la pile de capteurs Android. Chaque composant communique uniquement avec les composants situés juste au-dessus et en dessous, bien que certains les capteurs peuvent contourner le hub de capteurs s'il est présent. Les flux de contrôle les applications aux capteurs, et les données circulent des capteurs jusqu'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 (Software Development Kit). Le SDK contient des fonctions permettant de répertorier les capteurs disponibles et de s'enregistrer dans un capteur vidéo.
Lors de l'enregistrement auprès d'un capteur, l'application spécifie son échantillonnage préféré et ses exigences en termes de latence.
- Par exemple, une application peut s'enregistrer sur l'accéléromètre par défaut, demandant des événements à 100 Hz et en permettant de signaler des événements avec une fréquence la latence.
- L'application reçoit les événements de l'accéléromètre à une fréquence de 100 Hz au minimum, et avec un décalage d'une seconde maximum.
Pour en savoir plus sur le SDK, consultez la documentation destinée aux développeurs.
Framework
Le framework est chargé d'associer les différentes applications au HAL. Le HAL lui-même est un client unique. Sans ce multiplexage au niveau au niveau du framework, une seule application pouvait 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 sur le même capteur, le framework prend
des exigences du compte de chaque application et envoie la version mise à jour
au HAL.
- La fréquence d'échantillonnage correspond à la fréquence maximale des fréquences d'échantillonnage demandées. applications reçoivent les événements à une fréquence plus élevée que celle qu'elles demandée.
- La latence maximale des rapports sera la plus faible des latences demandées. Si une application en demande une avec une latence maximale de création de rapports de 0, toutes les applications reçoivent provenant de ce capteur en mode continu, même si certains l'ont demandé avec une latence maximale des rapports non nulle. Pour en savoir plus, consultez la section Traitement par lot.
- Lorsque la dernière application enregistrée pour un capteur se désinscrit de celui-ci, les frameworks envoient une requête au HAL pour désactiver le capteur afin que l'alimentation sont consommées inutilement.
Impact du multiplexage
Ce besoin d'une couche de multiplexage dans le framework explique certaines décisions.
- Lorsqu'une application demande une fréquence d'échantillonnage spécifique, garantir que les événements n'arriveront pas à un rythme plus rapide. Si une autre application a demandé le même capteur plus rapidement, la première application les recevoir rapidement.
- Le même manque de garantie s'applique à la latence de création de rapports maximale demandée: les applications peuvent recevoir des événements avec une latence nettement 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 des capteurs.
- Par exemple, imaginez un capteur physique capable de fonctionner à la fois en termes de fréquence précision" et "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 un autre un mode économie d'énergie ; il n'y aurait aucun moyen pour le cadre de satisfaire applications. Le framework doit toujours être en mesure de satisfaire tous ses clients, donc ce n'est pas une option.
- Il n'existe aucun mécanisme permettant d'envoyer les données des applications aux capteurs ou leurs pilotes. Ainsi, une application ne peut pas modifier le comportement des capteurs, ce qui a brisé d'autres applications.
Fusion de capteurs
Le framework Android fournit une implémentation par défaut pour certaines capteurs. Lorsqu'un appareil est équipé d'un gyroscope, d'un accéléromètre et d'un magnétomètre, mais qu'il n'y a pas de vecteur de rotation, de capteur de gravité et d'accélération linéaire, le framework implémente ces capteurs pour que les applications peuvent toujours les utiliser.
L'implémentation par défaut n'a pas accès à toutes les données que les autres les implémentations ont accès et il doit s'exécuter sur le SoC, il n'est donc pas aussi précise ni aussi économe en énergie que d'autres implémentations. Autant les fabricants d'appareils doivent définir leurs propres capteurs à fusibles (rotation la gravité et l'accélération linéaire, ainsi que les nouveaux capteurs composites le vecteur de rotation du jeu) plutôt que d'utiliser cette implémentation par défaut. Les fabricants d'appareils peuvent et demander aux fournisseurs de puces de leur fournir une implémentation.
La mise en œuvre par défaut de la fusion des capteurs n'est pas maintenue. peut entraîner l'échec de CTS sur les appareils qui s'en servent.
Détails techniques
Cette section est fournie à titre d'information générale pour les personnes qui gèrent Code du framework du projet Android Open Source (AOSP). Il n'est pas pertinent pour fabricants de matériel.
JNI
Le framework utilise une interface JNI (Java Native Interface) associée à android.hardware et située dans le répertoire frameworks/base/core/jni/. Ce code appelle la méthode
du 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 framework natif
équivalent au package android.hardware. Le framework natif appelle les proxys Binder IPC pour accéder
des services spécifiques aux capteurs.
Classeur IPC
Les proxys d’IPC de liaison facilitent la communication sur les limites des processus.
HAL
L'API Sensors Hardware Abstraction Layer (HAL) est l'interface entre les pilotes de matériel et le framework Android. Il se compose d'une interface HAL capteurs.h et une implémentation HAL appelée capteurs.cpp.
L'interface est définie par les contributeurs Android et AOSP, et est fournie par le fabricant de l'appareil.
L'interface HAL du capteur se trouve dans hardware/libhardware/include/hardware.
Consultez sensors.h.
pour en savoir plus.
Cycle de publication
L'implémentation HAL spécifie la version de l'interface
implémente en définissant your_poll_device.common.version. Le HAL existant
d'interface utilisateur sont définies dans "Sensors.h", et les fonctionnalités sont liées
versions.
Le framework Android prend actuellement en charge les versions 1.0 et 1.3, mais 1.0 le sera. ne seront bientôt plus disponibles. Cette documentation décrit le comportement d'un fichier 1.3, vers laquelle tous les appareils doivent être mis à niveau. Pour savoir comment passer à 1.3, consultez la section Obsolescence des versions HAL.
Pilote de noyau
Les pilotes de capteur interagissent avec les appareils physiques. Dans certains cas, le HAL l'implémentation et les pilotes constituent la même entité logicielle. Dans d’autres cas, l'intégrateur matériel demande aux fabricants de puces de capteurs de fournir mais ce sont eux qui écrivent l'implémentation HAL.
Dans tous les cas, l'implémentation HAL et les pilotes de noyau sont la responsabilité les fabricants de matériel, et Android ne propose 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 puissance, tandis que le SoC peut être dans un le mode suspendu. Par exemple, la comptabilisation des pas ou la fusion de capteurs peuvent être effectuées ces chips. C'est aussi l'endroit idéal pour le traitement par lot des capteurs, des FIFO matériels pour les événements des capteurs. Pour en savoir plus, consultez la section Traitement par lot.
Remarque:Pour développer de nouvelles fonctionnalités ContextHub qui utilisez de nouveaux capteurs ou LED, SensorHub Neonkey connecté à un carte de développement Hikey ou Hikey960.
La matérialisation du hub de capteurs dépend de l'architecture. Il est parfois une puce séparée, et parfois inclus sur la même puce que le SoC. Important les caractéristiques du hub de capteurs est qu'il doit contenir suffisamment de mémoire pour le traitement par lot et qui consomment très peu d'énergie pour permettre l'implémentation alimentent les capteurs Android. Certains hubs de capteurs contiennent un microcontrôleur pour le calcul et les accélérateurs matériels pour permettre des calculs à très faible puissance capteurs de faible consommation d'énergie.
L'architecture du hub de capteurs et la manière dont il communique avec les capteurs et le SoC (bus I2C, bus SPI, etc.) n'est pas spécifié par Android, mais il doit viser de réduire la consommation d'énergie globale.
Une option qui semble avoir un impact significatif sur l'implémentation la simplicité 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 réveil les interruptions (pour les capteurs qui ne sont pas activés).
Capteurs
Ce sont les puces MEM physiques qui effectuent les mesures. Dans de nombreux cas, plusieurs capteurs physiques sont présentés sur la même puce. Par exemple, certains chips un accéléromètre, un gyroscope et un magnétomètre. (Les chips 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 comme la détection des mouvements, la détection de pas et la fusion de capteurs sur 9 axes.
Bien que les exigences et recommandations en matière de puissance et de précision du CDD ciblent le aux capteurs Android et non aux capteurs physiques, ces exigences ont une incidence le choix des capteurs physiques. Par exemple, l'exigence de justesse vecteur de rotation influe sur la justesse requise pour la le gyroscope. Il appartient au fabricant de l'appareil de déterminer les exigences pour capteurs physiques.