Deprecazione della versione HAL

Nella versione L di Android, interromperemo il supporto per alcune versioni HAL dei sensori. Le uniche versioni supportate sono SENSORS_DEVICE_API_VERSION_1_0 e SENSORS_DEVICE_API_VERSION_1_3 .

Nelle prossime versioni è probabile che elimineremo anche il supporto per 1_0.

1_0 non ha il concetto di batching. Se possibile, tutti i dispositivi che utilizzano 1_0 DOVREBBERO eseguire l'aggiornamento a 1_3.

1_1 e 1_2 soffrono di una scarsa definizione del concetto di batch e non sono più supportati

Tutti i dispositivi che attualmente utilizzano 1_1 o 1_2 DEVONO eseguire l'aggiornamento a 1_3.

In 1_3 abbiamo semplificato il concetto di batching e abbiamo introdotto i sensori di attivazione.

Per eseguire l'aggiornamento a 1_3, seguire le modifiche elencate di seguito.

Implementare la funzione batch

Anche se non implementi il ​​batching (il tuo hardware non ha FIFO), devi implementare la funzione batch . batch viene utilizzato per impostare il periodo di campionamento e la latenza massima di reporting per un dato sensore. Sostituisce setDelay . setDelay non verrà più chiamato.

Se non implementi l'invio in batch , puoi implementarlo semplicemente chiamando la funzione setDelay esistente con il parametro sampling_period_ns fornito.

Implementare la funzione flush

Anche se non si implementa l'invio in batch, è necessario implementare la funzione flush .

Se non si implementa l'invio in batch, flush deve generare un evento META_DATA_FLUSH_COMPLETE e restituire 0 (successo).

Cambia il tuo sensori_poll_device_t.common.version

your_poll_device.common.version = SENSORS_DEVICE_API_VERSION_1_3

Aggiungi i nuovi campi alla definizione dei tuoi sensori

Quando si definisce ciascun sensore, oltre ai soliti campi 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,

è inoltre necessario impostare i nuovi campi, definiti tra 1_0 e 1_3:

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

fifoReservedEventCount : se non stai implementando il batch, impostalo su 0.

fifoMaxEventCount : se non si implementa il batching, impostarlo su 0

stringType : imposta su 0 per tutti i sensori Android ufficiali (quelli definiti in sensori.h), poiché questo valore verrà sovrascritto dal framework. Per i sensori non ufficiali, vedere sensor_t per i dettagli su come impostarlo.

requestPermission : questa è l'autorizzazione che le applicazioni dovranno avere per accedere al sensore. Di solito puoi impostarlo su 0 per tutti i tuoi sensori, ma i sensori con tipo HEART_RATE devono impostarlo su SENSOR_PERMISSION_BODY_SENSORS.

maxDelay : questo valore è importante e dovrai impostarlo in base alle capacità del sensore e del suo driver.

Questo valore è definito solo per sensori continui e in variazione. È il ritardo tra due eventi del sensore corrispondente alla frequenza più bassa supportata da questo sensore. Quando vengono richieste frequenze inferiori tramite la funzione batch , gli eventi verranno invece generati a questa frequenza. Può essere utilizzato dal framework o dalle applicazioni per stimare quando il FIFO batch potrebbe essere pieno. Se questo valore non è impostato correttamente, CTS fallirà. Per i sensori con modalità di reporting speciale e one-shot, impostare maxDelay su 0.

Per i sensori continui, impostarlo sul periodo di campionamento massimo consentito in microsecondi.

Quanto segue è applicabile a period_ns , maxDelay e minDelay :

  • period_ns è in nanosecondi mentre maxDelay / minDelay sono in microsecondi.
  • maxDelay dovrebbe sempre rientrare in un intero con segno a 32 bit. È dichiarato come 64 bit su architetture a 64 bit solo per motivi di compatibilità binaria.

flag : questo campo definisce la modalità di segnalazione del sensore e se il sensore è un sensore di sveglia.

Se non implementi il ​​batching e stai semplicemente passando da 1.0 a 1.3, impostalo su:

SENSOR_FLAG_WAKE_UP | SENSOR_FLAG_ONE_SHOT_MODE per sensori a scatto singolo

SENSOR_FLAG_CONTINUOUS_MODE per sensori continui SENSOR_FLAG_ON_CHANGE_MODE per sensori di variazione eccetto prossimità SENSOR_FLAG_SPECIAL_REPORTING_MODE per sensori con modalità di reporting speciale tranne il rilevatore di inclinazione .

SENSOR_FLAG_WAKE_UP | SENSOR_FLAG_ON_CHANGE_MODE per il sensore di prossimità e il sensore rilevatore di inclinazione ufficiale Android.

Note durante l'aggiornamento da 1_1 o 1_2

  • La funzione batch ora ha quasi sempre successo, anche per i sensori che non supportano il batch, indipendentemente dal valore dell'argomento timeout. Gli unici casi in cui la funzione batch potrebbe non riuscire sono errori interni o un sensor_handle, errato o sampling_period_ns negativo o un max_report_latency_ns negativo.
  • Se un sensore supporta l'invio in batch è definito dal fatto che abbia un fifoMaxEventCount maggiore di 0. (Nelle versioni precedenti, era basato sul valore restituito di batch() .)
  • I sensori che supportano il batching sono sempre in quella che nelle versioni precedenti chiamavamo "modalità batch": anche se il parametro max_report_latency_ns è 0, il sensore deve comunque essere batchato, ovvero gli eventi devono essere memorizzati nella FIFO quando il SoC passa alla modalità di sospensione .
  • Il parametro flags della funzione batch non viene più utilizzato. DRY_RUN e WAKE_UPON_FIFO_FULL sono entrambi deprecati e non verranno mai passati alla funzione batch .
  • L'argomento timeout batch viene ora definito argomento max_report_latency .