Ritiro della versione HAL

Nella release L di Android, interromperemo il supporto di alcune versioni dell'HAL del sensore. Le uniche versioni supportate sono SENSORS_DEVICE_API_VERSION_1_0 e SENSORS_DEVICE_API_VERSION_1_3.

Nelle prossime release, è probabile che rimuoviamo anche il supporto per 1_0.

1_0 non ha il concetto di raggruppamento. Se possibile, tutti i dispositivi che utilizzano 1_0 DEVONO eseguire l'upgrade a 1_3.

1_1 e 1_2 presentano una scarsa definizione del concetto di raggruppamento e non sono più supportati

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

Nella versione 1_3 abbiamo semplificato il concetto di raggruppamento e abbiamo introdotto i sensori di risveglio.

Per eseguire l'upgrade alla versione 1_3, segui le modifiche elencate di seguito.

Implementa la funzione batch

Anche se non implementi il batching (l'hardware non ha FIFO), devi implementare la funzione batch. batch viene utilizzato per impostare il periodo di campionamento e la latenza massima dei report per un determinato sensore. Sostituisci setDelay. setDelay non verrà più chiamato.

Se non implementi il batching, puoi implementare batch semplicemente chiamando la funzione setDelay esistente con il parametro sampling_period_ns fornito.

Implementa la funzione di svuotamento

Anche se non implementi il batching, devi implementare la funzioneflush.

Se non implementi il raggruppamento, flush deve generare un evento META_DATA_FLUSH_COMPLETE e restituire 0 (operazione riuscita).

Modificare sensors_poll_device_t.common.version

your_poll_device.common.version = SENSORS_DEVICE_API_VERSION_1_3

Aggiungi i nuovi campi alla definizione dei sensori

Quando definisci ogni sensore, oltre ai consueti 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,

Devi anche 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 implementi il raggruppamento, imposta questo valore su 0.

fifoMaxEventCount: se non implementi il raggruppamento, imposta questo valore su 0

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

requiredPermission: questa è l'autorizzazione che le applicazioni dovranno avere per accedere al sensore. In genere puoi impostare questo valore su 0 per tutti i sensori, ma per i sensori di tipo HEART_RATE deve essere impostato su SENSOR_PERMISSION_BODY_SENSORS.

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

Questo valore è definito solo per i sensori continui e con 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 generati a questa frequenza. Può essere utilizzato dal framework o dalle applicazioni per stimare quando il batch FIFO potrebbe essere pieno. Se questo valore non è impostato correttamente, il CTS non andrà a buon fine. Per i sensori con modalità di generazione di report una tantum e speciali, imposta maxDelay su 0.

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

Per period_ns, maxDelay e minDelay si applicano le seguenti norme:

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

flags: questo campo definisce la modalità di generazione di report del sensore e se si tratta di un sensore di riattivazione.

Se non implementi il raggruppamento e passi dalla versione 1.0 alla 1.3, imposta questo valore su:

SENSOR_FLAG_WAKE_UP | SENSOR_FLAG_ONE_SHOT_MODE per i sensori one-shot

SENSOR_FLAG_CONTINUOUS_MODE per i sensori continui SENSOR_FLAG_ON_CHANGE_MODE per i sensori al variare tranne quelli di prossimità SENSOR_FLAG_SPECIAL_REPORTING_MODE per i sensori con modalità di generazione di report speciali tranne il rilevatore di inclinazione.

SENSOR_FLAG_WAKE_UP | SENSOR_FLAG_ON_CHANGE_MODE per il sensore di prossimità e il sensore di rilevamento dell'inclinazione ufficiale di Android.

Note per l'upgrade da 1_1 o 1_2

  • La funzione batch ora riesce quasi sempre, anche per i sensori che non supportano il bagging, indipendentemente dal valore dell'argomento timeout. Gli unici casi in cui la funzione batch potrebbe non riuscire sono gli errori interni o un valore sensor_handle, o sampling_period_ns o max_report_latency_ns negativo errato.
  • Il supporto del raggruppamento da parte di un sensore è definito dal valore fifoMaxEventCount maggiore di 0. Nelle versioni precedenti, si basava sul valore restituito di batch().
  • I sensori che supportano il raggruppamento sono sempre in quella che chiamavamo "modalità batch" nelle versioni precedenti: anche se il parametro max_report_latency_ns è 0, il sensore deve comunque essere raggruppato, il che significa che gli eventi devono essere memorizzati nella coda 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 obsoleti e non verranno mai passati alla funzione batch.
  • L'argomento del timeout batch ora viene chiamato max_report_latency.