Desuso de la versión HAL

En la versión L de Android, dejaremos de admitir algunas versiones de sensores HAL. Las únicas versiones compatibles son SENSORS_DEVICE_API_VERSION_1_0 y SENSORS_DEVICE_API_VERSION_1_3 .

En las próximas versiones, es probable que también dejemos de admitir 1_0.

1_0 no tiene concepto de procesamiento por lotes. Si es posible, todos los dispositivos que usan 1_0 DEBEN actualizarse a 1_3.

1_1 y 1_2 adolecen de una mala definición del concepto de procesamiento por lotes y ya no son compatibles

Todos los dispositivos que actualmente usan 1_1 o 1_2 DEBEN actualizarse a 1_3.

En 1_3, simplificamos la noción de procesamiento por lotes e introdujimos sensores de activación.

Para actualizar a 1_3, siga los cambios que se enumeran a continuación.

Implementar la función por lotes

Incluso si no implementa el procesamiento por lotes (su hardware no tiene FIFO), debe implementar la función batch . batch se utiliza para establecer el período de muestreo y la latencia máxima de informes para un sensor determinado. Reemplaza setDelay . setDelay ya no será llamado.

Si no implementa el procesamiento por batch , puede implementarlo simplemente llamando a su función setDelay existente con el parámetro sampling_period_ns proporcionado.

Implementar la función de descarga.

Incluso si no implementa el procesamiento por lotes, debe implementar la función flush .

Si no implementa el procesamiento por lotes, flush debe generar un evento META_DATA_FLUSH_COMPLETE y devolver 0 (éxito).

Cambie su sensors_poll_device_t.common.version

your_poll_device.common.version = SENSORS_DEVICE_API_VERSION_1_3

Añade los nuevos campos a la definición de tus sensores

Al definir cada sensor, además de los campos habituales 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,

También debes configurar los nuevos campos, definidos entre 1_0 y 1_3:

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

fifoReservedEventCount : si no implementa el procesamiento por lotes, configúrelo en 0.

fifoMaxEventCount : si no implementa el procesamiento por lotes, establezca este en 0

stringType : se establece en 0 para todos los sensores oficiales de Android (aquellos que están definidos en sensors.h), ya que el marco sobrescribirá este valor. Para sensores no oficiales, consulte sensor_t para obtener detalles sobre cómo configurarlo.

requirePermission : este es el permiso que las aplicaciones deberán tener para acceder a su sensor. Por lo general, puedes configurar esto en 0 para todos tus sensores, pero los sensores con tipo HEART_RATE deben configurarlo en SENSOR_PERMISSION_BODY_SENSORS.

maxDelay : este valor es importante y deberá configurarlo de acuerdo con las capacidades del sensor y de su controlador.

Este valor se define sólo para sensores continuos y en cambio. Es el retraso entre dos eventos de sensor correspondiente a la frecuencia más baja que admite este sensor. Cuando se solicitan frecuencias más bajas a través de la función batch , los eventos se generarán en esta frecuencia. Puede ser utilizado por el marco o las aplicaciones para estimar cuándo el lote FIFO puede estar lleno. Si este valor no se establece correctamente, CTS fallará. Para sensores de modo de informe especial y de un solo disparo, establezca maxDelay en 0.

Para sensores continuos, configúrelo en el período de muestreo máximo permitido en microsegundos.

Lo siguiente se aplica a period_ns , maxDelay y minDelay :

  • period_ns está en nanosegundos, mientras que maxDelay / minDelay están en microsegundos.
  • maxDelay siempre debe caber dentro de un entero de 32 bits con signo. Se declara como de 64 bits en arquitecturas de 64 bits sólo por motivos de compatibilidad binaria.

banderas : este campo define el modo de informe del sensor y si el sensor es un sensor de activación.

Si no implementa el procesamiento por lotes y simplemente está pasando de 1.0 a 1.3, configúrelo en:

SENSOR_FLAG_WAKE_UP | SENSOR_FLAG_ONE_SHOT_MODE para sensores de un solo disparo

SENSOR_FLAG_CONTINUOUS_MODE para sensores continuos SENSOR_FLAG_ON_CHANGE_MODE para sensores en cambio excepto proximidad SENSOR_FLAG_SPECIAL_REPORTING_MODE para sensores con modo de informe especial excepto para el detector de inclinación .

SENSOR_FLAG_WAKE_UP | SENSOR_FLAG_ON_CHANGE_MODE para el sensor de proximidad y el sensor detector de inclinación oficial de Android.

Notas al actualizar desde 1_1 o 1_2

  • La función batch ahora casi siempre tiene éxito, incluso para sensores que no admiten el procesamiento por lotes, independientemente del valor del argumento de tiempo de espera. Los únicos casos en los que la función batch puede fallar son errores internos, un sensor_handle, un sampling_period_ns negativo o max_report_latency_ns negativo.
  • Si un sensor admite el procesamiento por lotes se define en función de si tiene un fifoMaxEventCount mayor que 0. (En versiones anteriores, se basaba en el valor de retorno de batch() ).
  • Los sensores que admiten el procesamiento por lotes siempre están en lo que llamamos "modo por lotes" en versiones anteriores: incluso si el parámetro max_report_latency_ns es 0, el sensor aún debe estar en lotes, lo que significa que los eventos deben almacenarse en el FIFO cuando el SoC pasa al modo de suspensión. .
  • El parámetro flags de la función batch ya no se utiliza. DRY_RUN y WAKE_UPON_FIFO_FULL están en desuso y nunca se pasarán a la función batch .
  • El argumento de tiempo de espera del lote ahora se denomina argumento max_report_latency .