Obsolescence de la version HAL

Dans la version L d'Android, nous arrêtons la prise en charge de certaines versions de capteur 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 pas de concept de traitement par lots. 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 traitement par lots et ne sont plus pris en charge

Tous les appareils utilisant actuellement 1_1 ou 1_2 DOIVENT être mis à niveau vers 1_3.

En 1_3, nous avons simplifié la notion de batching, et nous avons introduit des 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 de rapport maximale 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 par batch en appelant simplement votre fonction setDelay existante avec le paramètre sampling_period_ns fourni.

Implémenter la fonction flush

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).

Modifiez votre Sensors_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 définir 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 Sensors.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.

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

maxDelay : Cette valeur est importante et vous devrez la définir en fonction des capacités du capteur et de son pilote.

Cette valeur est définie uniquement pour les capteurs continus et sur changement. C'est le délai entre deux événements de capteur correspondant à la fréquence la plus basse que ce capteur supporte. Lorsque des fréquences inférieures sont demandées via la fonction batch , les événements seront générés à cette fréquence à la place. Il peut être utilisé par le cadre 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 ponctuel 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 à 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é 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 rapport 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 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 à un coup

SENSOR_FLAG_CONTINUOUS_MODE pour les capteurs continus SENSOR_FLAG_ON_CHANGE_MODE pour les capteurs de changement sauf la proximité SENSOR_FLAG_SPECIAL_REPORTING_MODE pour les capteurs avec mode de rapport 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.

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

  • La fonction de batch réussit désormais presque toujours, même pour les capteurs qui ne prennent pas en charge le traitement par lots, indépendamment de 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 un 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 a ou non un fifoMaxEventCount supérieur à 0. (Dans les versions précédentes, il était basé sur la valeur de retour de batch() .)
  • Les capteurs qui prennent en charge le traitement par lots sont toujours dans ce que nous appelions le "mode traitement par lots" dans les versions précédentes : même si le paramètre max_report_latency_ns est 0, le capteur doit toujours être traité par lots, ce qui signifie que les événements doivent être stockés dans le FIFO lorsque le SoC passe en mode suspendu. .
  • 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 de délai d'attente du lot est désormais appelé argument max_report_latency .