Baja de la versión de HAL

En la versión L de Android, suspenderemos la compatibilidad con algunas versiones de HAL de los sensores. 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 la versión 1_0.

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

1_1 y 1_2 tienen una definición deficiente del concepto de 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 lotes y presentamos los sensores de activación.

Para actualizar a la versión 1_3, sigue los cambios que se indican a continuación.

Implementa la función por lotes

Incluso si no implementas el procesamiento por lotes (tu hardware no tiene FIFO), debes implementar la función batch. batch se usa para establecer el período de muestreo y la latencia máxima de informes para un sensor determinado. Reemplaza setDelay. Ya no se llamará a setDelay.

Si no implementas el procesamiento por lotes, puedes implementar batch llamando a tu función setDelay existente con el parámetro sampling_period_ns proporcionado.

Implementa la función de limpieza

Incluso si no implementas el procesamiento por lotes, debes implementar la función flush.

Si no implementas el procesamiento por lotes, flush debe generar un evento META_DATA_FLUSH_COMPLETE y mostrar 0 (correcto).

Cambia tu sensors_poll_device_t.common.version

your_poll_device.common.version = SENSORS_DEVICE_API_VERSION_1_3

Agrega los campos nuevos a la definición de tus sensores

Cuando definas cada sensor, además de los campos sensor_t habituales, haz lo siguiente:

.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 campos nuevos, 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 implementas el procesamiento por lotes, configúralo en 0.

fifoMaxEventCount: Si no implementas el procesamiento por lotes, configúralo en 0.

stringType: Se establece en 0 para todos los sensores oficiales de Android (los que se definen en sensors.h), ya que el framework reemplazará este valor. Para los sensores no oficiales, consulta sensor_t y obtén detalles sobre cómo configurarlos.

requiredPermission: Este es el permiso que las aplicaciones deberán tener para obtener acceso a tu sensor. Por lo general, puedes establecer este valor en 0 para todos los sensores, pero los sensores con el tipo HEART_RATE deben establecerlo en SENSOR_PERMISSION_BODY_SENSORS..

maxDelay: Este valor es importante y deberás configurarlo según las capacidades del sensor y su controlador.

Este valor solo se define para sensores continuos y de cambio. Es la demora entre dos eventos del sensor que corresponden a la frecuencia más baja que admite este sensor. Cuando se soliciten frecuencias más bajas a través de la función batch, los eventos se generarán a esta frecuencia. El framework o las aplicaciones pueden usarlo para estimar cuándo es posible que el FIFO por lotes esté lleno. Si este valor no se establece correctamente, CTS fallará. Para los sensores de modo de informes especiales y únicos, establece maxDelay en 0.

Para los sensores continuos, configúralo 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 en un número entero de 32 bits con firma. Se declara como de 64 bits en arquitecturas de 64 bits solo por motivos de compatibilidad binaria.

flags: Este campo define el modo de informes del sensor y si es un sensor de activación.

Si no implementas el procesamiento por lotes y solo pasas de la versión 1.0 a la 1.3, establece lo siguiente:

SENSOR_FLAG_WAKE_UP | SENSOR_FLAG_ONE_SHOT_MODE para sensores únicos

SENSOR_FLAG_CONTINUOUS_MODE para sensores continuos, SENSOR_FLAG_ON_CHANGE_MODE para sensores con cambio, excepto el de proximidad, y SENSOR_FLAG_SPECIAL_REPORTING_MODE para sensores con modo de informes especial, excepto el detector de inclinación.

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

Notas para actualizar desde 1_1 o 1_2

  • La función batch ahora casi siempre se realiza correctamente, 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 batch podría fallar son los errores internos, o bien un sensor_handle, incorrecto, o bien un sampling_period_ns o max_report_latency_ns negativo.
  • La compatibilidad de un sensor con el procesamiento por lotes se define según si tiene un fifoMaxEventCount mayor que 0. (En versiones anteriores, se basaba en el valor que se muestra de batch()).
  • Los sensores que admiten el procesamiento por lotes siempre están en lo que llamamos el “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 batch ya no se usa. DRY_RUN y WAKE_UPON_FIFO_FULL están obsoletos y nunca se pasarán a la función batch.
  • El argumento de tiempo de espera por lotes ahora se conoce como argumento max_report_latency.