L'interface HAL des capteurs, déclarée dans sensors.h, représente l'interface entre le framework Android et le sur les logiciels spécifiques au matériel. Une implémentation HAL doit définir chaque fonction déclaré dans "Sensors.h". Les principales fonctions sont les suivantes:
get_sensors_list: renvoie la liste de tous les capteurs.activate: démarre ou arrête un capteur.batch: définit les paramètres d'un capteur, tels que la fréquence d'échantillonnage et la valeur maximale la latence des rapports.setDelay: utilisé uniquement dans la version 1.0 de HAL. Définit la fréquence d'échantillonnage d'une un capteur donné.flush: vide le FIFO du capteur spécifié et signale un vidage terminé. une fois l'opération terminée.poll: renvoie les événements de capteurs disponibles.
L'implémentation doit être thread-safe et permettre l'appel de ces fonctions à partir de différents threads.
L'interface définit également plusieurs types utilisés par ces fonctions. La principale types sont:
sensors_module_tsensors_poll_device_tsensor_tsensors_event_t
En plus des sections ci-dessous, consultez sensors.h pour en savoir plus sur ces types.
get_sensors_list(liste)
int (*get_sensors_list)(struct sensors_module_t* module, struct sensor_t const** list);
Fournit la liste des capteurs implémentés par le HAL. Consultez la section sensor_t pour en savoir plus sur la définition des capteurs.
L'ordre dans lequel les capteurs apparaissent dans la liste correspond à l'ordre dans lequel les capteurs sont transmis aux applications. En général, les capteurs de la base puis les capteurs composites.
Si plusieurs capteurs partagent le même type de capteur et la même propriété d'activation, le premier
l'un des capteurs de la liste est le capteur par défaut. C'est celle renvoyée par
getDefaultSensor(int sensorType, bool wakeUp)
Cette fonction renvoie le nombre de capteurs dans la liste.
enable(capteur, vrai/faux)
int (*activate)(struct sensors_poll_device_t *dev, int sensor_handle, int enabled);
Active ou désactive un capteur.
sensor_handle est la poignée du capteur à activer/désactiver. Un capteur
handle est défini par le champ handle de sa structure sensor_t.
enabled est défini sur 1 pour activer le capteur ou sur 0 pour le désactiver.
Les capteurs ponctuels se désactivent automatiquement lors de la réception d'un événement.
et ils doivent tout de même accepter la désactivation en appelant activate(...,
enabled=0).
Les capteurs qui ne sont pas de veille n'empêchent jamais le SoC de passer en mode suspendu. que le HAL ne doit pas maintenir un wakelock partiel pour le compte des applications.
Les capteurs de veille, lorsqu'ils envoient des événements en continu, peuvent empêcher le SoC de en mode suspendu, mais si aucun événement n'est nécessaire, le wakelock doit être libéré.
Si enabled est défini sur 1 et que le capteur est déjà activé, cette fonction est une fonction no-op.
et réussit.
Si enabled est défini sur 0 et que le capteur est déjà désactivé, cette fonction est une fonction no-op.
et réussit.
Cette fonction renvoie 0 en cas de réussite et un nombre d'erreur négatif dans le cas contraire.
batch(capteur, options, période d'échantillonnage, latence maximale des rapports)
int (*batch)(
struct sensors_poll_device_1* dev,
int sensor_handle,
int flags,
int64_t sampling_period_ns,
int64_t max_report_latency_ns);
Définit les paramètres d'un capteur, y compris la fréquence d'échantillonnage et rapport maximum la latence du réseau. Cette fonction peut être appelée lorsque le capteur est activé, Dans ce cas, les mesures des capteurs ne doivent pas être perdues. d'un taux d'échantillonnage à l'autre ne peuvent pas entraîner de pertes d'événements, passer d'une latence maximale élevée à une faible latence maximale des rapports la latence.
sensor_handle est la poignée du capteur à configurer.
flags n'est actuellement pas utilisé.
sampling_period_ns est la période d'échantillonnage
au cours de laquelle le capteur
doit s'exécuter en nanosecondes. Voir sampling_period_ns pour
plus de détails.
max_report_latency_ns est la durée maximale avant laquelle les événements peuvent être
avant d'être transmis via le HAL, en nanosecondes. Reportez-vous à la métrique max_report_Latency_ns.
pour en savoir plus.
Cette fonction renvoie 0 en cas de réussite et un nombre d'erreur négatif dans le cas contraire.
setDelay(capteur, période d'échantillonnage)
int (*setDelay)(
struct sensors_poll_device_t *dev,
int sensor_handle,
int64_t sampling_period_ns);
Après la version 1.0 de HAL, cette fonction est obsolète et n'est jamais appelée.
Au lieu de cela, la fonction batch est appelée pour définir le
Paramètre sampling_period_ns.
Dans la version 1.0 de HAL, setDelay était utilisé au lieu du lot pour définir sampling_period_ns.
vidange(capteur)
int (*flush)(struct sensors_poll_device_1* dev, int sensor_handle);
Ajoutez un événement de vidage complet à la fin du FIFO matériel pour le capteur spécifié et videz le FIFO. ces événements sont diffusés normalement (comme si la latence maximale des rapports expirée) et supprimée du FIFO.
Le vidage s'effectue de manière asynchrone (en d'autres termes, le résultat de cette fonction doit être immédiat). 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 (pas de mise en mémoire tampon possible), ou si le FIFO est
était vide au moment de l'appel, flush doit quand même réussir et
envoyer un événement de vidage complet pour ce capteur. Cela s'applique à tous les capteurs
que les capteurs uniques.
Lorsque flush est appelé, même si un événement de vidage se trouve déjà dans le
FIFO pour ce capteur, vous devez en créer un supplémentaire et l'ajouter à la fin
du FIFO, et celui-ci doit être vidé. Nombre de flush
doit être égal au nombre d'événements de vidage terminé créés.
flush ne s'applique pas aux modes one-shot
les capteurs ; si sensor_handle fait référence à un capteur one-shot,
flush doit renvoyer -EINVAL et n'en générer aucun
l'événement de vidage complet des métadonnées.
Cette fonction renvoie 0 en cas de réussite, -EINVAL si le capteur spécifié est un
capteur one-shot ou n'était pas activé, et un nombre d'erreur négatif dans le cas contraire.
poll()
int (*poll)(struct sensors_poll_device_t *dev, sensors_event_t* data, int count);
Renvoie un tableau de données de capteurs en remplissant l'argument data. Cette fonction
doit être bloqué jusqu'à ce que des événements soient disponibles. Elle renvoie le nombre d'événements lus
en cas de réussite, ou un nombre d'erreur négatif en cas d'erreur.
Le nombre d'événements renvoyés dans data doit être inférieur ou égal à
l'argument count. Cette fonction ne renvoie jamais 0 (aucun événement).
Séquence d'appels
Lorsque l'appareil démarre, get_sensors_list est appelé.
Lorsqu'un capteur est activé, la fonction batch est appelée avec la méthode
les paramètres demandés, suivis de activate(..., enable=1).
Notez que dans la version 1_0 de HAL, l'ordre était inverse: activate a été appelé.
en premier, suivi de set_delay.
Lorsque les caractéristiques demandées d'un capteur changent pendant qu'il est
activée, la fonction batch est appelée.
flush peut être appelé à tout moment, même sur des capteurs non activés (auquel cas
la valeur -EINVAL doit être renvoyée)
Lorsqu'un capteur est désactivé, activate(..., enable=0) est appelé.
Parallèlement à ces appels, la fonction poll est appelée à plusieurs reprises pour :
demander des données. poll peut être appelé même si aucun capteur n'est activé.
capteurs_module_t
sensors_module_t est le type utilisé pour créer le matériel Android.
pour les capteurs. L'implémentation du HAL doit définir un objet
HAL_MODULE_INFO_SYM de ce type pour exposer la fonction get_sensors_list. Consultez le
définition de sensors_module_t dans sensors.h et de la définition de hw_module_t
pour en savoir plus.
capteurs_poll_device_t / capteurs_poll_device_1_t
sensors_poll_device_1_t contient les autres méthodes définies ci-dessus:
activate, batch, flush et
poll Son champ common (de type hw_device_t)
définit le numéro de version du HAL.
capteur_t
sensor_t représente un
capteur. Voici quelques-uns de ses champs importants:
name:chaîne visible par l'utilisateur et représentant le capteur. Souvent, cette chaîne contient le nom de la pièce du capteur sous-jacent, le type de capteur et qu'il s'agisse d'un capteur de réveil. Exemple : "Accéléromètre LIS2HH12". "MAX21000 Uncalibrated Gyroscope", "BMP280 Wake-up Barometer", "MPU6515 Game" "Vecteur de rotation"
handle:entier utilisé pour faire référence au capteur lors de son enregistrement ou générer des événements à partir de celui-ci.
type:type de capteur. Voir les explications sur le capteur
saisissez Qu'est-ce qu'un capteur Android ? pour en savoir plus, et consultez Types de capteurs pour connaître les types de capteurs officiels. Pour
Types de capteurs non officiels, type doit commencer par SENSOR_TYPE_DEVICE_PRIVATE_BASE
stringType:type du capteur sous forme de chaîne. Lorsque
le type du capteur est officiel (SENSOR_STRING_TYPE_*). Quand ?
le capteur est d'un type spécifique au fabricant, stringType doit
par le nom de domaine inversé du fabricant. Par exemple, un capteur (par exemple,
(détecteur de licorne), défini par l'équipe Cool-product
Fictif-Entreprise
pourrait utiliser
stringType=”com.fictional_company.cool_product.unicorn_detector”
stringType permet d'identifier de manière unique les capteurs non officiels.
de données. Consultez la page sensors.h pour en savoir plus sur les types et les chaînes.
de données.
requiredPermission:chaîne représentant l'autorisation
que les applications doivent posséder pour voir le capteur, s'y enregistrer et recevoir
de ses données. Une chaîne vide signifie que les applications ne nécessitent aucune autorisation
accéder à ce capteur. Certains types de capteurs, tels que le moniteur de fréquence cardiaque, ont un
requiredPermission obligatoire. Tous les capteurs fournissant des informations
les informations sur l'utilisateur (comme la fréquence cardiaque) doivent être protégées par un
l'autorisation.
flags (indicateurs) : indicateurs associés à ce capteur, définissant le mode de signalement du capteur et
le capteur est un capteur d'activation ou non. Par exemple, un capteur d'activation ponctuelle
aura flags = SENSOR_FLAG_ONE_SHOT_MODE | SENSOR_FLAG_WAKE_UP. Les bits de
l'indicateur qui n'est pas utilisé dans la version actuelle de HAL doit rester égal à 0.
maxRange:valeur maximale que le capteur peut signaler, dans la même unité que la valeur
les valeurs enregistrées. Le capteur doit pouvoir transmettre des valeurs sans saturer
dans un rayon de [-maxRange; maxRange]. Notez que cela correspond à la plage totale
au sens générique est 2*maxRange. Lorsque le capteur indique des valeurs supérieures à
plusieurs axes, la plage s'applique à chacun d'entre eux. Par exemple, "+/- 2g"
l'accéléromètre indique maxRange = 2*9.81 = 2g.
résolution:la plus petite différence de valeur que le capteur peut mesurer.
Généralement calculé en fonction de maxRange et du nombre de bits dans la mesure.
power:coût énergétique de l'activation du capteur, en milliampères.
C'est presque toujours plus que la consommation d'énergie indiquée dans
du capteur sous-jacent. Voir Capteurs de base != Physique
capteurs pour en savoir plus, et consultez l'article sur la mesure de la puissance
pour savoir comment mesurer la consommation d'énergie d'un capteur.
Si la consommation d'énergie du capteur varie selon que l'appareil est en mouvement,
la consommation d'énergie pendant vos déplacements est celle indiquée dans les power
.
minDelay:pour les capteurs continus, la période d'échantillonnage, exprimée en
microsecondes, ce qui correspond au débit le plus rapide accepté par le capteur. Voir sampling_period_ns pour
des détails sur l'utilisation de cette valeur. Attention : minDelay est
exprimé en microsecondes alors que sampling_period_ns correspond à
nanosecondes. Pour les capteurs en cas de changement ou en mode de rapport spécial, sauf si
sinon minDelay doit être défini sur 0. Pour les capteurs one-shot,
doit être définie sur -1.
maxDelay:pour les capteurs en continu et en cas de changement, l'échantillonnage
moyenne, exprimée en microsecondes, correspondant à la vitesse la plus lente
compatibles. Voir sampling_period_ns pour
des détails sur l'utilisation de cette valeur. Attention : maxDelay est
exprimé en microsecondes alors que sampling_period_ns correspond à
nanosecondes. Pour les capteurs spéciaux et ponctuels, maxDelay doit être
0.
fifoRéservéEventCount:nombre d'événements réservés pour ce capteur dans le champ
FIFO matériel. S'il existe un FIFO dédié pour ce capteur,
fifoReservedEventCount est la taille de ce FIFO dédié. Si le FIFO est
partagée avec d'autres capteurs, fifoReservedEventCount est la taille de la partie de
le FIFO réservé à ce capteur. Sur la plupart des systèmes FIFO partagés et sur
systèmes sans FIFO matériel,
cette valeur est 0.
fifoMaxEventCount:nombre maximal d'événements pouvant
dans les FIFO de ce capteur. Cette valeur est toujours supérieure ou égale à
fifoReservedEventCount Cette valeur est utilisée
pour estimer comment
le FIFO se remplit vite
lors de l'enregistrement sur le capteur
en supposant qu'aucun autre capteur ne soit activé. Sur les systèmes qui n'ont pas
FIFO matériel, fifoMaxEventCount est 0. Pour en savoir plus, consultez la section Traitement par lot.
Pour les capteurs associés à un type de capteur officiel, certains champs sont écrasés.
par le framework. C'est le cas, par exemple, des capteurs de l'accéléromètre.
sont tenus d'avoir un mode de création de rapport continu, et les moniteurs de fréquence cardiaque sont
d'être protégés par le SENSOR_PERMISSION_BODY_SENSORS
l'autorisation.
capteurs_événement_t
Les événements générés par les capteurs Android et signalés via la fonction poll sont de type type sensors_event_t. Voici quelques exemples
champs importants de sensors_event_t:
version:doit être sizeof(struct sensors_event_t)
sensor:handle du capteur ayant généré l'événement, tel que défini par
sensor_t.handle
type:type du capteur ayant généré l'événement, tel que défini par
sensor_t.type
timestamp:horodatage de l'événement en nanosecondes. C'est l'heure à laquelle
(un pas a été effectué ou une mesure a été effectuée par l'accéléromètre),
et non à l'heure à laquelle
l'événement a été signalé. timestamp doit être synchronisé avec le
elapsedRealtimeNano et, dans le cas de capteurs continus, la gigue
doit être petite. Le filtrage du code temporel est parfois nécessaire pour respecter le CDD
comme n'utiliser que le temps d'interruption
SoC pour définir les horodatages
provoque une gigue trop élevée. Si vous n'utilisez que le temps de puce du capteur
les codes temporels peuvent provoquer une désynchronisation
horloge elapsedRealtimeNano, car l'horloge du capteur dérive.
données et champs qui se chevauchent:valeurs mesurées par le
capteur vidéo. La signification et les unités de ces champs sont propres à chaque capteur.
de mots clés. Consultez le fichier sensors.h et la définition des différents types de capteurs pour obtenir une description des
des champs de données. Pour certains capteurs, la précision des mesures est également indiquée
dans les données, via un champ status. Ce champ est uniquement
pour ces types de capteurs spécifiques, qui apparaissent au niveau de la couche du SDK
la valeur de précision. Pour ces capteurs, le fait que le champ "status"
est mentionné dans leur type de capteur.
définition.
Événements de vidage des métadonnées terminés
Les événements de métadonnées sont du même type que les événements de capteurs normaux:
sensors_event_meta_data_t = sensors_event_t Elles sont renvoyées avec
et d'autres événements de capteurs. Ils possèdent les champs suivants:
version:doit être META_DATA_VERSION
type:doit être SENSOR_TYPE_META_DATA
sensor, budget, réservé et code temporel: doit être égal à 0.
meta_data.what:contient le type de métadonnées de cet événement. Il existe actuellement
Un seul type de métadonnées valide: META_DATA_FLUSH_COMPLETE.
Les événements META_DATA_FLUSH_COMPLETE représentent la fin du vidage d'un
capteur FIFO. Lorsque meta_data.what=META_DATA_FLUSH_COMPLETE, meta_data.sensor
doit être réglée sur la poignée du capteur qui a été vidé. Il s'agit
généré quand et seulement lorsque flush est appelé sur un capteur. Consultez la section sur
la fonction flush pour plus d'informations.