Google is committed to advancing racial equity for Black communities. See how.
Cette page a été traduite par l'API Cloud Translation.
Switch to English

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, bien que certains capteurs puissent contourner le concentrateur de capteurs lorsqu'il est présent. Le contrôle des flux depuis les applications jusqu'aux capteurs, et les données des capteurs jusqu'aux 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 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 sur 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 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 en charge de relier les différentes applications au HAL . Le HAL lui-même est un 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 à la HAL pour activer le capteur.
  • Lorsque des applications supplémentaires s'inscrivent sur le même capteur, le framework prend en compte les exigences de chaque application et envoie les paramètres demandés mis à jour à la 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 maximum sera la minimum 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 Batching pour plus de détails.
  • Lorsque la dernière application enregistrée sur un capteur se désenregistre, les frameworks envoient une demande au HAL pour désactiver le capteur afin de ne pas consommer inutilement de l'énergie.

Impact du multiplexage

Ce besoin d'une couche de multiplexage dans le cadre explique certaines décisions de conception.

  • Lorsqu'une application demande une fréquence d'échantillonnage spécifique, il n'y a aucune garantie 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.
  • Le même manque de garantie s'applique à la latence de rapport maximale demandée: les applications peuvent recevoir des événements avec beaucoup moins de latence qu'elles ne l'ont demandé.
  • 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 modes «haute précision» et «faible puissance».
    • 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 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 les données des applications aux capteurs ou à leurs pilotes. Cela garantit qu'une application ne peut pas modifier le comportement des capteurs, interrompant 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 cadre 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. 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 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 de fusion de capteur par défaut 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 en tant qu'informations générales pour ceux qui gèrent le code du framework Android Open Source Project (AOSP). Cela ne concerne pas les fabricants de matériel.

JNI

Le framework utilise une interface Java Native (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.

Cadre natif

Le framework natif est défini dans frameworks/native/ et fournit un équivalent natif du package android.hardware . Le framework natif appelle les proxys Binder IPC pour accéder aux services spécifiques aux capteurs.

Classeur IPC

Les proxys IPC Binder facilitent la communication au-delà des limites du 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 capteurs.cpp.

L'interface est définie par les contributeurs Android et AOSP, et la mise en œuvre est fournie par le fabricant de l'appareil.

L'interface HAL du capteur se trouve dans hardware/libhardware/include/hardware . Voir Sensor.h pour plus de détails.

Cycle de libération

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 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 périphériques doivent être mis à niveau. Pour plus de détails sur la mise à niveau vers la version 1.3, consultez obsolète 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 capteurs de fournir les pilotes, mais ce sont eux qui écrivent l'implémentation HAL.

Dans tous les cas, l'implémentation HAL et les pilotes du noyau sont de la responsabilité des fabricants de matériel, et Android ne propose pas les approches préférées pour les écrire.

Hub 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 alors que le SoC peut être en mode suspension. Par exemple, un comptage de pas ou une fusion de capteur peut être effectué sur ces puces. C'est également un bon endroit pour mettre en œuvre le traitement par lots des capteurs, en ajoutant des FIFO matériels pour les événements de capteur. Voir Batching pour plus d'informations.

Remarque: pour développer de nouvelles fonctionnalités ContextHub utilisant de nouveaux capteurs ou LED, vous pouvez également utiliser un capteur Neonkey SensorHub connecté à une carte de développement Hikey ou Hikey960.

La manière dont le concentrateur de capteurs est matérialisé 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 basse consommation. Certains concentrateurs de capteurs contiennent un microcontrôleur pour le calcul générique et des accélérateurs matériels pour permettre le calcul de très faible puissance pour les capteurs de 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é par Android, mais il doit viser à minimiser la consommation d'énergie globale.

Une option qui semble avoir un impact significatif sur la simplicité de mise en œuvre est d'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 comprennent 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 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éterminer les exigences relatives aux capteurs physiques.