Estados de energía del SoC
Los estados de energía del sistema en un chip (SoC) son: encendido, inactivo y suspendido. "Encendido" es cuando el SoC está funcionando. "Inactivo" es un modo de potencia media en el que el SoC está encendido pero no realiza ninguna tarea. "Suspender" es un modo de bajo consumo en el que el SoC no recibe alimentación. El consumo de energía del dispositivo en este modo suele ser 100 veces menor que en el modo "Encendido".
Sensores que no despiertan
Los sensores que no se activan son sensores que no impiden que el SoC entre en modo de suspensión y no lo activan para informar datos. En particular, a los conductores no se les permite utilizar wake-locks. Es responsabilidad de las aplicaciones mantener un bloqueo de activación parcial si desean recibir eventos de sensores que no son de activación mientras la pantalla está apagada. Mientras el SoC está en modo de suspensión, los sensores deben continuar funcionando y generando eventos, que se colocan en un FIFO de hardware. (Consulte Procesamiento por lotes para obtener más detalles). Los eventos en FIFO se entregan a las aplicaciones cuando el SoC se activa. Si el FIFO es demasiado pequeño para almacenar todos los eventos, los eventos más antiguos se pierden; los datos más antiguos se eliminan para dar cabida a los datos más recientes. En el caso extremo en el que el FIFO no existe, se perderán todos los eventos generados mientras el SoC está en modo de suspensión. Una excepción es el último evento de cada sensor en cambio: el último evento debe guardarse fuera del FIFO para que no se pueda perder.
Tan pronto como el SoC sale del modo de suspensión, se informan todos los eventos del FIFO y las operaciones se reanudan con normalidad.
Las aplicaciones que utilizan sensores que no son de activación deben mantener un bloqueo de activación para garantizar que el sistema no se suspenda, cancelar el registro de los sensores cuando no los necesiten o esperar perder eventos mientras el SoC está en modo de suspensión.
Sensores de despertador
A diferencia de los sensores que no son de activación, los sensores de activación garantizan que sus datos se entreguen independientemente del estado del SoC. Mientras el SoC está activo, los sensores de activación se comportan como sensores sin activación. Cuando el SoC está inactivo, los sensores de activación deben activar el SoC para generar eventos. Aún así deben dejar que el SoC entre en modo de suspensión, pero también deben reactivarlo cuando sea necesario informar de un evento. Es decir, el sensor debe activar el SoC y entregar los eventos antes de que haya transcurrido la latencia máxima de informes o que el hardware FIFO se llene. Consulte Procesamiento por lotes para obtener más detalles.
Para garantizar que las aplicaciones tengan tiempo de recibir el evento antes de que el SoC vuelva a entrar en modo de suspensión, el conductor debe mantener un "bloqueo de activación por tiempo de espera" durante 200 milisegundos cada vez que se informa un evento. Es decir, no se debe permitir que el SoC vuelva a dormir en los 200 milisegundos posteriores a una interrupción del despertar. Este requisito desaparecerá en una versión futura de Android y necesitamos este bloqueo de activación por tiempo de espera hasta entonces.
¿Cómo definir sensores de despertador y no despertador?
Hasta KitKat, si un sensor era un sensor de despertador o no de despertador dependía del tipo de sensor: la mayoría eran sensores de no despertador, con la excepción del sensor de proximidad y el detector de movimiento significativo .
Comenzando en L, si un sensor determinado es un sensor de despertador o no se especifica mediante un indicador en la definición del sensor. La mayoría de los sensores pueden definirse mediante pares de variantes de activación y no activación del mismo sensor, en cuyo caso deben comportarse como dos sensores independientes, sin interactuar entre sí. Consulte Interacción para obtener más detalles.
A menos que se especifique lo contrario en la definición del tipo de sensor, se recomienda implementar un sensor de activación y un sensor de no activación para cada tipo de sensor enumerado en Tipos de sensores . En cada definición de tipo de sensor, vea qué sensor (activado o no activado) devolverá SensorManager.getDefaultSensor(sensorType) . Es el sensor que utilizarán la mayoría de aplicaciones.