Obsolescencia de la versión HAL

En la versión L de Android, detendremos la compatibilidad con algunas versiones HAL del sensor. Las únicas versiones compatibles son SENSORS_DEVICE_API_VERSION_1_0 y SENSORS_DEVICE_API_VERSION_1_3 .

En los próximos lanzamientos, es probable que también eliminemos el soporte para 1_0.

1_0 no tiene concepto de procesamiento por lotes. Si es posible, todos los dispositivos que usen 1_0 DEBERÍAN actualizarse a 1_3.

1_1 y 1_2 tienen una definición deficiente del concepto de procesamiento por lotes y ya no se admiten

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 por 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 se llamará.

Si no implementa el procesamiento por lotes, puede implementar el procesamiento por batch 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 de flush .

Si no implementa el procesamiento por lotes, META_DATA_FLUSH_COMPLETE flush devolver 0 (éxito).

Cambie su sensor_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 sensor_t habituales:

.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 debe establecer 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, establezca este en 0.

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

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

Permiso requerido : este es el permiso que las aplicaciones deberán tener para acceder a su sensor. Por lo general, puede establecer esto en 0 para todos sus sensores, pero los sensores con tipo HEART_RATE deben establecer esto 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 solo para sensores continuos y de cambio. Es el retraso entre dos eventos de sensor correspondientes a la frecuencia más baja que soporta este sensor. Cuando se solicitan frecuencias más bajas a través de la función de 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 una sola acción, establezca maxDelay en 0.

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

Lo siguiente es aplicable para 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 con signo de 32 bits. Se declara como de 64 bits en arquitecturas de 64 bits solo por razones 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 solo está pasando de 1.0 a 1.3, establezca esto en:

SENSOR_FLAG_WAKE_UP | SENSOR_FLAG_ONE_SHOT_MODE para sensores de disparo único

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 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 por batch ahora casi siempre tiene éxito, incluso para los 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 por batch puede fallar son los errores internos, o un sensor_handle, o sampling_period_ns negativo o max_report_latency_ns negativo.
  • Si un sensor admite el procesamiento por lotes se define 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 procesarse por 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 por 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 por batch .
  • El argumento de tiempo de espera del lote ahora se denomina argumento max_report_latency .