Abandon de la version HAL

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

Dans les prochaines versions, il est probable que la prise en charge de 1_0 ne soit également plus assurée.

1_0 n'a pas de concept de traitement par lot. Si possible, tous les appareils utilisant 1_0 DOIVENT mettre à niveau vers 1_3.

1_1 et 1_2 souffrent d'une mauvaise définition du concept de traitement par lot et ne sont pas désormais compatibles

Tous les appareils qui utilisent actuellement 1_1 ou 1_2 DOIVENT être mis à niveau vers la version 1_3.

Dans 1_3, nous avons simplifié la notion de traitement par lot et nous avons présenté l'activation capteurs.

Pour passer à la version 1_3, appliquez les modifications indiquées ci-dessous.

Implémenter la fonction de traitement par lot

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

Si vous n'implémentez pas le traitement par lot, vous pouvez implémenter batch en Il vous suffit d'appeler votre fonction setDelay existante avec le code sampling_period_ns.

Implémenter la fonction de vidage

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

Si vous n'implémentez pas le traitement par lot, flush doit en générer une. META_DATA_FLUSH_COMPLETE et renvoie 0 (succès).

Modifier le paramètre "Sensors_poll_device_t.common.version"

your_poll_device.common.version = SENSORS_DEVICE_API_VERSION_1_3

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

Lors de la définition de chaque capteur, en plus des valeurs habituelles de sensor_t :

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

fifoRéservéEventCount: si vous n'implémentez pas le traitement par lot, définissez ce paramètre sur 0.

fifoMaxEventCount: si vous n'implémentez pas le traitement par lot, définissez cette valeur sur 0.

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

requiredPermission: il s'agit de l'autorisation que les applications devront avoir pour accéder l'accès à votre capteur. Vous pouvez généralement la 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 doit être définie en fonction du du capteur et de son pilote.

Cette valeur n'est définie que pour les capteurs en continu et en cas de changement. Il s'agit entre deux événements de capteur correspondant à la fréquence la plus basse que cette capteurs compatibles. Lorsque des fréquences basses sont demandées via la classe batch, les événements sont générés à cette fréquence à la place. Il peut être utilisé par le framework ou les applications pour estimer à quel moment Le lot FIFO est peut-être saturé. Si cette valeur n'est pas définie correctement, CTS échouera. Pour les capteurs ponctuels ou spéciaux en mode de rapport, définissez maxDelay sur 0.

Pour les capteurs continus, définissez la période d'échantillonnage maximale autorisée microsecondes.

Les conditions suivantes s'appliquent à period_ns, maxDelay et minDelay:

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

flags: ce champ définit le mode de signalement du capteur et indique s'il est un capteur d'activation.

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

SENSOR_FLAG_WAKE_UP | SENSOR_FLAG_ONE_SHOT_MODE pour one-shot capteurs

SENSOR_FLAG_CONTINUOUS_MODE pour continue capteurs SENSOR_FLAG_ON_CHANGE_MODE pour en cas de changement capteurs, sauf la proximité SENSOR_FLAG_SPECIAL_REPORTING_MODE pour les capteurs avec spécial mode de création de rapports, à l'exception de l'inclinaison .

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

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

  • Désormais, la fonction batch réussit presque toujours, même pour les capteurs qui ne sont pas compatibles par lot, indépendamment de la valeur de l'argument de délai d'inactivité. Les seuls cas où la fonction batch peut échouer sont des erreurs internes ou une mauvaise sensor_handle, ou négatif sampling_period_ns ou max_report_latency_ns à exclure.
  • La compatibilité d'un capteur avec le traitement par lot dépend de la présence ou non d'une fifoMaxEventCount supérieure à 0. (Dans les versions précédentes, il était en fonction de la valeur renvoyée par batch().)
  • Les capteurs qui prennent en charge le traitement par lot sont toujours dans les versions précédentes: même si le paramètre max_report_latency_ns est défini sur 0, le capteur doit toujours être regroupé, c'est-à-dire que les événements doivent être stocké dans le FIFO lorsque le SoC passe en mode suspendu.
  • Le paramètre flags de la fonction batch est ne sont plus utilisées. DRY_RUN et WAKE_UPON_FIFO_FULL sont sont obsolètes et ne seront jamais transmises à la fonction batch.
  • L'argument de délai d'attente par lot est maintenant appelé l'argument max_report_latency.