Pile de capteurs

La figure ci-dessous représente la pile de capteurs Android. Chaque composant communique uniquement avec les composants 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.

Couches et propriétaires de la pile de capteurs Android

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 auprès d'un capteur, l'application spécifie sa fréquence d'échantillonnage préférée et ses exigences en matière de latence.

  • Par exemple, une application peut s'enregistrer sur l'accéléromètre par défaut, demander des événements à 100 Hz et permettre aux événements d'ê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, 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 au 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 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 maximale des fréquences d'échantillonnage demandées, ce qui signifie que certaines applications recevront des événements à une fréquence supérieure à celle demandée.
    • La latence maximale de reporting sera la minimale 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 Traitement par lots pour plus de détails.
  • Lorsque la dernière application enregistrée sur un capteur s'en désinscrit, les frameworks envoient une demande au 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 plus rapidement. Si une autre application demande le même capteur à un rythme plus rapide, la première application les recevra également à un rythme plus rapide.
  • Le même manque de garantie s’applique à la latence maximale de rapport 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 capable de fonctionner à la fois en mode « haute précision » et « faible 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 le 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'existe aucun mécanisme pour envoyer des données depuis les applications vers les capteurs ou leurs pilotes. Cela garantit qu’une application ne peut pas modifier le comportement des capteurs, interrompant ainsi 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 d'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 peuvent l'être. Dans la mesure du possible, les fabricants d'appareils devraient 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 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 maintenue et peut entraîner l’échec du CTS sur les appareils qui en dépendent.

Sous la capuche

Cette section est fournie à titre d'informations générales pour ceux qui gèrent le code-cadre du projet Android Open Source (AOSP). Cela ne concerne pas 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 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 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, sensor.h, et d'une implémentation HAL, que nous appelons sensor.cpp.

L'interface est définie par les contributeurs Android et AOSP, et la mise en œuvre 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 quelle version de l'interface HAL elle implémente en définissant your_poll_device.common.version . Les versions d'interface HAL existantes sont définies dans sensor.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 Dépréciation de la version HAL .

Pilote de noyau

Les pilotes de capteurs interagissent avec les appareils physiques. Dans certains cas, l'implémentation HAL 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 les pilotes, mais ce sont eux qui rédigent l'implémentation de 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 propose pas d'approches privilégiées pour les écrire.

Concentrateur de capteur

La pile de capteurs d'un appareil peut éventuellement inclure un hub de capteurs, utile pour effectuer des calculs de bas niveau à faible consommation tandis que le SoC peut être en mode suspension. Par exemple, un comptage de pas ou une fusion de capteurs peuvent être effectués sur ces puces. C'est également un bon endroit pour implémenter le traitement par lots de capteurs, en ajoutant des FIFO matériels pour les événements de capteur. Voir Traitement par lots pour plus d'informations.

Remarque : Pour développer de nouvelles fonctionnalités de ContextHub utilisant de nouveaux capteurs ou 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 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 lots et consommer très peu d'énergie pour permettre la mise en œuvre des capteurs Android à faible consommation. 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 pour les capteurs à faible consommation.

L'architecture du hub de capteurs et la manière dont il communique avec les capteurs et le SoC (bus I2C, bus SPI, …) n'est pas spécifiée par Android, mais elle devrait viser à minimiser la consommation globale d'énergie.

Une option qui semble avoir un impact significatif sur la simplicité de mise en œuvre consiste à disposer de 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 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 une 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 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 du CDD en matière de puissance et de précision 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 d'en déduire les exigences relatives aux capteurs physiques.