La couche d'abstraction matérielle (HAL, Sensors Hardware Abstraction Layer) le framework de capteur Android et les capteurs d'un appareil, tels qu'un accéléromètre ou le gyroscope. Le HAL des capteurs définit les fonctions à implémenter pour de contrôler les capteurs.
Le HAL des capteurs AIDL est disponible sur Android 13 et pour les appareils neufs et plus récents. Sensors AIDL HAL, basé sur Sensors HAL 2.1 utilise le interface HAL AIDL et expose le capteur de tête et les capteurs de la centrale inertielle à axe limité.
Interface HAL AIDL
La principale source de documentation sur le HAL des capteurs AIDL se trouve dans le HAL définition à hardware/interfaces/sensors/aidl/android/hardware/sensors/ISensors.aidl.
Implémenter le HAL des capteurs AIDL
Pour implémenter le HAL Sensors AIDL, un objet doit étendre le ISensors
et implémenter toutes les fonctions définies dans
hardware/interfaces/sensors/aidl/android/hardware/sensors/ISensors.aidl.
Initialiser l'HAL
Le HAL des capteurs doit être initialisé par le framework de capteurs Android avant
peuvent être utilisées. Le framework appelle la fonction initialize() pour fournir trois
au HAL des capteurs: deux descripteurs FMQ et un pointeur vers
ISensorsCallback.
Le HAL utilise le premier descripteur pour créer le FMQ de l'événement utilisé pour écrire le capteur
d'événements dans le framework. Le HAL utilise le deuxième descripteur pour créer le Wake
Verrouillage de FMQ utilisé pour la synchronisation lorsque le HAL libère son wakelock pour WAKE_UP
les événements de capteurs. Le HAL doit enregistrer un pointeur vers l'objet ISensorsCallback.
que toutes les fonctions de rappel nécessaires puissent être appelées.
La fonction initialize() doit être la première fonction appelée lors de l'initialisation.
l'HAL des capteurs.
Exposer les capteurs disponibles
Pour obtenir la liste de tous les capteurs statiques disponibles dans l'appareil, utilisez la
fonction getSensorsList(). Cette fonction renvoie une liste de capteurs,
identifié de manière unique
par son identifiant. La poignée d'un capteur donné ne doit pas changer.
lorsque le processus hébergeant le HAL des capteurs redémarre. Les identifiants peuvent changer
l'appareil et lors des redémarrages
du serveur système.
Si plusieurs capteurs partagent le même type de capteur et la même propriété d'activation, le
le premier capteur de la liste est appelé "capteur par défaut" et est renvoyé
Applications qui utilisent le getDefaultSensor(int sensorType, bool wakeUp)
.
Stabilité de la liste des capteurs
Après le redémarrage du HAL des capteurs, si les données renvoyées par getSensorsList()
indique un changement significatif par rapport à la liste de capteurs récupérée avant la
le framework déclenche un redémarrage du
Environnement d'exécution Android Les modifications importantes apportées à la liste des capteurs sont les cas
d'un capteur avec une poignée donnée est manquant ou dont les attributs ont changé, ou lorsque de nouveaux
les capteurs sont présentés. Bien que le redémarrage de l'environnement d'exécution Android soit perturbant
à l'utilisateur, elle est obligatoire, car le framework Android ne peut plus répondre aux
Le contrat de l'API Android stipule que les capteurs statiques (non dynamiques) ne changent pas pendant le
d'une application. Cela peut également empêcher le framework de rétablir
les demandes de capteurs actives effectuées par les applications. Par conséquent, les fournisseurs HAL sont invités à
pour empêcher les modifications évitables
de la liste des capteurs.
Pour garantir la stabilité des poignées des capteurs, le HAL doit mapper de manière déterministe capteur physique de l'appareil à sa poignée. Même si aucune mise en œuvre spécifique est imposée par l'interface HAL des capteurs, les développeurs disposent de plusieurs options pour répondre à cette exigence.
Par exemple, il est possible de trier la liste des capteurs en combinant les valeurs
des attributs fixes, tels que le fournisseur, le modèle et le type de capteur. Une autre option repose sur
sur le fait que l'ensemble de capteurs statiques de l'appareil est fixe dans le matériel.
HAL doit savoir quand tous les capteurs attendus ont terminé l'initialisation avant
retour de getSensorsList(). Cette liste de
les capteurs attendus peuvent être compilés dans le binaire HAL ou stockés dans un
fichier de configuration dans le système de fichiers, et l'ordre d'apparition peut être utilisé
pour obtenir des identifiants stables. Bien que la meilleure solution dépende de la configuration
des détails spécifiques sur l'implémentation, la principale exigence est que le capteur
ne changent pas lors des redémarrages HAL.
Configurer les capteurs
Avant d'activer un capteur, celui-ci doit être configuré avec un échantillonnage
période et latence maximale des rapports à l'aide de la fonction batch().
Un capteur doit pouvoir être reconfiguré à tout moment à l'aide de batch() sans le
la perte de données des capteurs.
Période d'échantillonnage
La période d'échantillonnage a une signification différente selon le type de capteur en cours de configuration:
- Continu: les événements des capteurs sont générés en continu.
- Lors de l'évolution: les événements sont générés au plus tôt que la période d'échantillonnage et peuvent être générées à un taux plus lent que la période d'échantillonnage si la valeur mesurée ne change pas.
- One-shot: la période d'échantillonnage est ignorée.
- Spécial: Pour en savoir plus, consultez Types de capteurs
Pour en savoir plus sur l'interaction entre une période d'échantillonnage et la température les modes de création de rapports, consultez Modes de création de rapports.
Latence maximale des rapports
La latence maximale des rapports définit la durée maximale, en nanosecondes, pendant laquelle peuvent être retardés et stockés dans le FIFO matériel avant d'être écrits dans l'événement FMQ via le HAL lorsque le SoC est activé.
La valeur zéro signifie que les événements doivent être consignés dès qu'ils sont soit sans le FIFO, soit en le vidant dès qu'il un événement du capteur est présent dans le FIFO.
Par exemple, un accéléromètre activé à 50 Hz avec un rapport maximal latence sur zéro déclenche 50 interruptions par seconde lorsque le SoC est activé.
Lorsque la latence maximale des rapports est supérieure à zéro, les événements de capteurs doivent être signalés dès leur détection. Les événements peuvent être temporaires stockés dans le FIFO matériel et transmis par lots, à condition qu'aucun événement ne soit plus tard que la latence maximale des rapports. Tous les événements depuis le le lot précédent sont enregistrés et renvoyés en même temps. Cela réduit le nombre de des interruptions envoyées au SoC et lui permet de passer à un mode d'économie d'énergie pendant la capture et le traitement par lot des données par le capteur.
Chaque événement est associé à un code temporel. En retardant le moment auquel une l'événement signalé ne doit pas avoir d'incidence sur son code temporel. Le code temporel doit être et correspondent à l'heure à laquelle l'événement s'est produit physiquement, et non à l'heure à laquelle elles ont été signalées.
Pour en savoir plus et connaître les exigences liées à la création de rapports sur les événements de capteurs avec une latence de création de rapports maximale différente de zéro, consultez la section Traitement par lot.
Activer les capteurs
Le framework active et désactive les capteurs à l'aide de la fonction activate().
Avant d'activer un capteur, l'infrastructure doit d'abord le configurer
avec batch().
Lorsqu'un capteur est désactivé, aucun autre événement ne doit être associé à ce capteur. être écrit dans le FMQ de l'événement.
Vidage des capteurs
Si un capteur est configuré pour traiter les données par lot, le framework peut forcer
un vidage immédiat des événements de capteurs par lot en appelant flush() ; Cela provoque
les événements de capteur regroupés pour la poignée de capteur spécifiée
écrit dans le FMQ de l'événement. Le HAL des capteurs doit ajouter un événement de vidage complet.
à la fin des événements de capteurs écrits à la suite d'un appel à
flush()
Le vidage s'effectue de manière asynchrone. En d'autres termes, cette fonction doit renvoyer immédiatement). Si l'implémentation utilise un seul FIFO pour plusieurs capteurs, celui-ci est et l'événement de vidage complet n'est ajouté que pour le capteur spécifié.
Si le capteur spécifié n'a pas de FIFO (mise en mémoire tampon impossible) ou si le FIFO était
vide au moment de l'appel, flush() doit quand même réussir et envoyer un vidage
l'événement complet associé à ce capteur. Cela s'applique à tous les capteurs autres que les capteurs uniques
capteurs.
Si flush() est appelé pour un capteur one-shot, flush() doit renvoyer
BAD_VALUE et ne pas générer d'événement de vidage complet.
Écrire les événements de capteurs dans le FMQ
Le FMQ des événements est utilisé par le HAL des capteurs pour transmettre les événements de capteurs à Android. de capteurs.
Le FMQ d'événement est un FMQ synchronisé, ce qui signifie que toute tentative d'écriture de données supplémentaires d'événements au FMQ que l'espace disponible ne le permet, l'écriture. Dans ce cas, le HAL doit déterminer s'il faut écrire l'ensemble actuel d'événements sous forme de deux plus petits groupes d'événements ou pour écrire tous les événements lorsque l'espace disponible est suffisant.
Lorsque l'HAL des capteurs a écrit le nombre souhaité d'événements de capteurs dans le
FMQ d'événement, le HAL des capteurs doit avertir le framework que les événements sont prêts
en écrivant le bit EventQueueFlagBits::READ_AND_PROCESS dans le FMQ de l'événement
fonction EventFlag::wake. L'indicateur d'événement peut être créé à partir de l'instance FMQ de l'événement
à l'aide de EventFlag::createEventFlag et du getEventFlagWord() de FMQ de l'événement
.
Le HAL des capteurs AIDL est compatible avec write et writeBlocking sur le FMQ d'événement.
L'implémentation par défaut fournit une référence pour l'utilisation de write. Si le
writeBlocking est utilisée, l'option readNotification doit être définie sur
EventQueueFlagBits::EVENTS_READ, qui est défini par le framework lorsqu'il lit
des événements FMQ d'événement. L'indicateur de notification d'écriture doit être défini sur
EventQueueFlagBits::READ_AND_PROCESS, qui informe le framework que les événements
ont été écrites dans le FMQ de l'événement.
Événements WAKE_UP
Les événements WAKE_UP sont des événements de capteur qui amènent le processeur d'application (PA)
et de gérer l'événement immédiatement. Chaque fois qu'un événement WAKE_UP est écrit
à l'événement FMQ, les capteurs HAL doivent sécuriser un wakelock pour garantir que
le système reste activé jusqu'à ce que le framework puisse gérer l'événement. À la réception d'un
WAKE_UP, le framework sécurise son propre wakelock, ce qui permet
Les capteurs HAL doivent déverrouiller son wakelock. Pour synchroniser les capteurs HAL
lève son wakelock, utilisez Wake Lock FMQ.
Le HAL des capteurs doit lire le FMQ du wakelock pour déterminer le nombre de WAKE_UP
gérés par le framework. Le HAL doit uniquement
libérer son wakelock
pour les événements WAKE_UP si le nombre total d'événements WAKE_UP non gérés est de zéro.
Après avoir géré les événements de capteurs, le framework compte le nombre d'événements
marqués comme événements WAKE_UP et réécrit ce nombre dans le FMQ de Wake Lock.
Le framework définit l'autorisation d'écriture WakeLockQueueFlagBits::DATA_WRITTEN
sur Wake Lock FMQ chaque fois qu'il écrit des données dans Wake Lock FMQ.
Capteurs dynamiques
Les capteurs dynamiques sont des capteurs qui ne sont pas physiquement intégrés à l'appareil, mais qui peuvent peut servir d'entrée à l'appareil, par exemple une manette de jeu avec un accéléromètre.
Lorsqu'un capteur dynamique est connecté, la fonction onDynamicSensorConnected dans
ISensorsCallback doit être appelé depuis le HAL des capteurs. Cela permet d'informer
du nouveau capteur dynamique et de le contrôler
via le framework et faire en sorte que les événements
du capteur soient utilisés par les clients.
De même, lorsqu'un capteur dynamique est déconnecté,
La fonction onDynamicSensorDisconnected dans ISensorsCallback doit être appelée ainsi
que le framework puisse supprimer tout capteur qui n'est plus disponible.
Canal direct
Le canal direct est une méthode d'opération dans laquelle les événements de capteurs sont écrits
une mémoire spécifique au lieu d'être transmis à l'événement FMQ, en contournant les capteurs Android
Framework. Un client qui enregistre un canal direct doit lire les événements de capteurs
directement à partir de la mémoire utilisée pour créer le canal direct et ne
recevoir les événements de capteurs via le framework. configDirectReport()
est semblable à batch() pour un fonctionnement normal et configure la fonction
signaler un canal.
Les fonctions registerDirectChannel() et unregisterDirectChannel() créent
ou supprimer un nouveau canal direct.
Modes de fonctionnement
La fonction setOperationMode() permet au framework de configurer un capteur
afin que le framework puisse y injecter des données. Ceci est utile pour
en particulier pour les algorithmes situés en dessous du framework.
En général, la fonction injectSensorData() permet de transférer
dans le HAL des capteurs. Cette fonction peut aussi être utilisée pour injecter
dans un capteur spécifique.
Validation
Pour valider votre implémentation du HAL des capteurs, exécutez les outils CTS et VTS du capteur. tests.
Tests CTS
Les tests CTS du capteur existent à la fois dans les tests CTS automatisés et dans le vérificateur CTS manuel l'application.
Les tests automatisés sont situés cts/tests/sensor/src/android/hardware/cts. Ces tests vérifient le fonctionnement standard des capteurs, comme l'activation les capteurs, le traitement par lot et les taux d'événements des capteurs.
Les tests du vérificateur CTS se trouvent cts/apps/CtsVerifier/src/com/android/cts/verifier/sensors Ces tests nécessitent une intervention manuelle de l'opérateur de test et s'assurent que les capteurs indiquent des valeurs précises.
Il est essentiel de réussir les tests CTS pour s'assurer que l'appareil soumis aux tests respecte les toutes les exigences du CDD.
Tests VTS
Les tests VTS pour le HAL des capteurs AIDL sont situés dans
hardware/interfaces/sensors/aidl/vts/.
Ces tests permettent de s'assurer que le HAL des capteurs est correctement implémenté et que tous
les exigences dans ISensors.aidl et ISensorsCallback.aidl sont correctement satisfaites.
Initialiser l'HAL
La fonction initialize() doit être compatible pour établir des FMQ entre les
framework et HAL.
Exposer les capteurs disponibles
Dans le HAL Sensors AIDL, la fonction getSensorsList() doit renvoyer la même valeur
pendant le démarrage d'un seul appareil, même lors des redémarrages HAL des capteurs. Une nouvelle exigence
de la fonction getSensorsList() est qu'elle doit renvoyer la même valeur pendant
un seul démarrage d'appareil, même lors des redémarrages HAL des capteurs. Cela permet
pour tenter de rétablir les connexions des capteurs si le serveur système
redémarre automatiquement. La valeur renvoyée par getSensorsList() peut changer après que l'appareil
effectue un redémarrage.
Écrire les événements de capteurs dans le FMQ
Au lieu d'attendre que poll() soit appelé, dans le HAL Sensors AIDL, les capteurs
HAL doit écrire de manière proactive les événements de capteurs dans le FMQ d'événement chaque fois que des événements de capteur
sont disponibles. Le HAL est également responsable
de l'écriture des bits corrects dans
EventFlag pour provoquer une lecture FMQ dans le framework.
Événements WAKE_UP
Dans la version 1.0 des capteurs HAL, le HAL a pu déverrouiller son wakelock pour n'importe quelle WAKE_UP
lors de tout appel ultérieur à poll() après la publication d'un WAKE_UP sur
poll(), car cela indique que l'infrastructure avait traité tous les capteurs
et obtenu un wakelock, si nécessaire. En effet, dans Sensors AIDL,
HAL, le HAL n'est plus averti lorsque le framework a traité des événements
écrit dans le FMQ, le Wake Lock FMQ permet au framework de communiquer
HAL lorsqu'il a géré des événements WAKE_UP.
Dans le HAL des capteurs AIDL, le wakelock sécurisé par le HAL des capteurs pour WAKE_UP
les événements doivent commencer par SensorsHAL_WAKEUP.
Capteurs dynamiques
Les capteurs dynamiques ont été renvoyés à l'aide de la fonction poll() dans Sensors HAL 1.0.
Le HAL des capteurs AIDL exige que onDynamicSensorsConnected et
onDynamicSensorsDisconnected dans ISensorsCallback doit être appelé chaque fois que des éléments dynamiques
les connexions des capteurs changent. Ces rappels sont disponibles
Pointeur ISensorsCallback fourni via la fonction initialize().
Modes de fonctionnement
Le mode DATA_INJECTION des capteurs WAKE_UP doit être compatible.
Compatibilité multi-HAL
Le HAL des capteurs AIDL est compatible avec plusieurs HAL à l'aide de la Framework Multi-HAL pour les capteurs : Pour les détails de l'implémentation, consultez Transfert depuis Sensors HAL 2.1