Baja de la versión de HAL

En la versión L de Android, detendremos la compatibilidad con algunos sensores HAL. versiones. 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 ser compatible con 1_0.

1_0 no tiene el concepto de agrupación en lotes. Si es posible, todos los dispositivos que usan 1_0 DEBEN actualizar a 1_3.

1_1 y 1_2 se ven afectadas por una mala definición del concepto de lotes y no son ya no es compatible

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

En 1_3, simplificamos la noción de agrupación en lotes e introdujimos la función de despertar sensores.

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 implementa la función batch. batch se usa para establecer el período de muestreo y la latencia máxima de informe para un sensor determinado. Integra reemplaza a setDelay. No se llamará a setDelay sus datos.

Si no implementas el procesamiento por lotes, puedes implementar batch. simplemente llamando a la función setDelay existente con el Parámetro sampling_period_ns.

Implementa la función de limpieza

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

Si no implementas el procesamiento por lotes, flush debe generar uno. META_DATA_FLUSH_COMPLETE y muestra 0 (correcto).

Cambia tu sensor_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 del sensor_t habitual campos:

.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 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 estás implementando el procesamiento por lotes, establece este en 0.

fifoMaxEventCount: Si no se implementa el procesamiento por lotes, establece este en 0.

stringType: establecer en 0 para todos los sensores oficiales de Android (los que se definen en sensores.h), ya que el framework reemplazará este valor. Para sensores no oficiales, consulta sensor_t para detalles sobre cómo configurarlo.

requiredPermission: Es el permiso que las aplicaciones deberán tener acceso al sensor. Por lo general, puedes establecerlo en 0 para todos los sensores, pero los sensores con el tipo HEART_RATE deben establecer esto en SENSOR_PERMISSION_BODY_SENSORS.

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

Este valor solo se define para los sensores continuos y en caso de cambio. Es el entre dos eventos de sensor que corresponden a la frecuencia más baja a la que es compatible con el sensor. Cuando se solicitan frecuencias más bajas mediante el función batch, los eventos se generarán con esta frecuencia en su lugar. Lo pueden usar el framework o las aplicaciones para estimar cuándo el FIFO del lote puede estar lleno. Si este valor no se establece correctamente, el CTS fallará. Para los sensores del modo de informe único y especial, establece maxDelay en 0.

Para sensores continuos, establécelo 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 ajustarse a un número entero firmado de 32 bits. Integra se declara como de 64 bits en arquitecturas de 64 bits solo por motivos de compatibilidad binaria.

flags: Este campo define el modo de informe del sensor y si este se un sensor de activación.

Si no implementas el procesamiento por lotes y solo pasarás de la 1.0 a la 1.3, configura lo siguiente: a:

SENSOR_FLAG_WAKE_UP | SENSOR_FLAG_ONE_SHOT_MODE para un intento sensores

SENSOR_FLAG_CONTINUOUS_MODE para continuo sensores SENSOR_FLAG_ON_CHANGE_MODE para cuando se produce un cambio sensores excepto de proximidad SENSOR_FLAG_SPECIAL_REPORTING_MODE para sensores con especial de generación de informes, excepto por la inclinación detector.

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

Notas cuando se actualiza desde 1_1 o 1_2

• La función batch ahora casi siempre se ejecuta de forma correcta, incluso para los sensores que no son compatibles. procesamiento por lotes, independiente del valor del argumento tiempo de espera. Los únicos casos en los que la función batch podría fallar son errores internos o sensor_handle, o negativo sampling_period_ns o max_report_latency_ns negativo.
• La posibilidad de que un sensor admita el procesamiento por lotes se define por si tiene fifoMaxEventCount mayor que 0. (En versiones anteriores, era según el valor que se muestra de batch()).
• Los sensores que admiten la agrupación por lotes están siempre en lo que llamamos “mode” en versiones anteriores: incluso si el parámetro max_report_latency_ns es 0, el sensor aún debe agruparse en lotes, lo que significa que los eventos deben en el FIFO cuando el SoC pasa al modo de suspensión.
• El parámetro flags de la función batch es que ya no se usan. DRY_RUN y WAKE_UPON_FIFO_FULL son son obsoletos y nunca se pasan a la función batch.
• El argumento del tiempo de espera del lote ahora se conoce como max_report_latency.