Dépréciation de la version HAL

Dans la version L d'Android, nous arrêtons la prise en charge de certaines versions de capteurs HAL. Les seules versions prises en charge sont SENSORS_DEVICE_API_VERSION_1_0 et SENSORS_DEVICE_API_VERSION_1_3 .

Dans les prochaines versions, nous abandonnerons probablement également la prise en charge de 1_0.

1_0 n'a aucune notion de batching. Si possible, tous les appareils utilisant 1_0 DEVRAIENT passer à 1_3.

1_1 et 1_2 souffrent d'une mauvaise définition du concept de batching et ne sont plus pris en charge

Tous les appareils utilisant actuellement 1_1 ou 1_2 DOIVENT passer à 1_3.

En 1_3, nous avons simplifié la notion de batching, et nous avons introduit les capteurs de réveil.

Pour passer à 1_3, suivez les modifications répertoriées ci-dessous.

Implémenter la fonction batch

Même si vous n'implémentez pas le batching (votre matériel n'a pas de FIFO), vous devez implémenter la fonction batch . batch est utilisé pour définir la période d’échantillonnage et la latence maximale de rapport pour un capteur donné. Il remplace setDelay . setDelay ne sera plus appelé.

Si vous n'implémentez pas le traitement par lots, vous pouvez implémenter le traitement batch en appelant simplement votre fonction setDelay existante avec le paramètre sampling_period_ns fourni.

Implémenter la fonction de chasse d'eau

Même si vous n'implémentez pas le traitement par lots, vous devez implémenter la fonction flush .

Si vous n'implémentez pas le traitement par lots, flush doit générer un événement META_DATA_FLUSH_COMPLETE et renvoyer 0 (succès).

Changez votre sensor_poll_device_t.common.version

your_poll_device.common.version = SENSORS_DEVICE_API_VERSION_1_3

Ajoutez les nouveaux champs à la définition de vos capteurs

Lors de la définition de chaque capteur, en plus des champs sensor_t habituels :

.name =       "My magnetic field Sensor",
.vendor =     "My company",
.version
=    1,
.handle =     mag_handle,
.type =       SENSOR_TYPE_MAGNETIC_FIELD,
.maxRange =   200.0f,
.resolution = CONVERT_M,
.power =      5.0f,
.minDelay =
 16667,

vous devez également paramétrer les nouveaux champs, définis entre 1_0 et 1_3 :

.fifoReservedEventCount = 0,
.fifoMaxEventCount =   0,
.stringType =         0,
.requiredPermission = 0,
.maxDelay =      200000
.flags =
SENSOR_FLAG_CONTINUOUS_MODE,

fifoReservedEventCount : si vous n'implémentez pas le traitement par lots, définissez celui-ci sur 0.

fifoMaxEventCount : Si vous n'implémentez pas le traitement par lots, définissez celui-ci sur 0

stringType : défini sur 0 pour tous les capteurs Android officiels (ceux qui sont définis dans capteurs.h), car cette valeur sera écrasée par le framework. Pour les capteurs non officiels, voir sensor_t pour plus de détails sur la façon de le configurer.

requisPermission : Il s’agit de l’autorisation que les applications devront avoir pour accéder à votre capteur. Vous pouvez généralement définir cette valeur sur 0 pour tous vos capteurs, mais les capteurs de type HEART_RATE doivent la définir sur SENSOR_PERMISSION_BODY_SENSORS.

maxDelay : Cette valeur est importante et vous devrez la régler en fonction des capacités du capteur et de son driver.

Cette valeur est définie uniquement pour les capteurs continus et à changement. C'est le délai entre deux événements de capteur correspondant à la fréquence la plus basse supportée par ce capteur. Lorsque des fréquences inférieures sont demandées via la fonction batch , les événements seront générés à cette fréquence. Il peut être utilisé par le framework ou les applications pour estimer quand le lot FIFO peut être plein. Si cette valeur n'est pas définie correctement, CTS échouera. Pour les capteurs en mode de rapport unique et spécial, définissez maxDelay sur 0.

Pour les capteurs continus, réglez-le sur la période d'échantillonnage maximale autorisée en microsecondes.

Les éléments suivants s'appliquent pour period_ns , maxDelay et minDelay :

  • period_ns est en nanosecondes alors que maxDelay / minDelay sont en microsecondes.
  • maxDelay doit toujours tenir dans un entier signé de 32 bits. Il est déclaré en 64 bits sur les architectures 64 bits uniquement pour des raisons de compatibilité binaire.

flags : Ce champ définit le mode de reporting du capteur et si le capteur est un capteur de réveil.

Si vous n'implémentez pas le traitement par lots et que vous passez simplement de la version 1.0 à la version 1.3, définissez ceci sur :

SENSOR_FLAG_WAKE_UP | SENSOR_FLAG_ONE_SHOT_MODE pour les capteurs ponctuels

SENSOR_FLAG_CONTINUOUS_MODE pour les capteurs continus SENSOR_FLAG_ON_CHANGE_MODE pour les capteurs sur changement sauf proximité SENSOR_FLAG_SPECIAL_REPORTING_MODE pour les capteurs avec mode de reporting spécial sauf pour le détecteur d'inclinaison .

SENSOR_FLAG_WAKE_UP | SENSOR_FLAG_ON_CHANGE_MODE pour le capteur de proximité et le capteur de détecteur d'inclinaison officiel Android.

Notes lors de la mise à niveau depuis 1_1 ou 1_2

  • La fonction batch réussit désormais presque toujours, même pour les capteurs qui ne prennent pas en charge le traitement par lots, quelle que soit la valeur de l'argument timeout. Les seuls cas où la fonction batch peut échouer sont des erreurs internes, ou un mauvais sensor_handle, ou sampling_period_ns négatif ou un max_report_latency_ns négatif.
  • Le fait qu'un capteur prenne en charge le traitement par lots est défini par le fait qu'il ait un fifoMaxEventCount supérieur à 0. (Dans les versions précédentes, il était basé sur la valeur de retour de batch() .)
  • Les capteurs prenant en charge le batching sont toujours dans ce que nous appelions le « mode batch » dans les versions précédentes : même si le paramètre max_report_latency_ns est 0, le capteur doit toujours être batch, ce qui signifie que les événements doivent être stockés dans le FIFO lorsque le SoC passe en mode suspension. .
  • Le paramètre flags de la fonction batch n'est plus utilisé. DRY_RUN et WAKE_UPON_FIFO_FULL sont tous deux obsolètes et ne seront jamais transmis à la fonction batch .
  • L’argument du délai d’expiration du lot est désormais appelé argument max_report_latency .