Estados de energia do SoC
Os estados de energia do system on a chip (SoC) são: ligado, inativo e suspenso. "On" é quando o SoC está em execução. "Ocioso" é um modo de energia média em que o SoC é ligado, mas não realiza nenhuma tarefa. "Suspensão" é um modo de baixo consumo de energia em que o SoC não está ligado. O consumo de energia do dispositivo nesse modo geralmente é 100 vezes menor do que no modo "Ligado".
Sensores que não ativam o dispositivo
Os sensores sem ativação não impedem que o SoC entre no modo de suspensão e não ativam o SoC para informar dados. Em particular, os drivers não podem manter os wake-locks. É responsabilidade dos aplicativos manter um wake lock parcial se eles quiserem receber eventos de sensores que não sejam de ativação enquanto a tela estiver desligada. Enquanto o SoC estiver no modo de suspensão, os sensores precisam continuar funcionando e gerar eventos, que são colocados em um FIFO de hardware. Consulte Processamento em lote para mais detalhes. Os eventos na FIFO são entregues aos aplicativos quando o SoC é ativado. Se a FIFO for muito pequena para armazenar todos os eventos, os mais antigos serão perdidos. Os dados mais antigos serão descartados para acomodar os dados mais recentes. No caso extremo em que o FIFO não existe, todos os eventos gerados enquanto o SoC está no modo de suspensão são perdidos. Uma exceção é o evento mais recente de cada sensor de mudança: o último evento precisa ser salvo fora da FIFO para não ser perdido.
Assim que o SoC sai do modo de suspensão, todos os eventos do FIFO são informados, e as operações são retomadas normalmente.
Os apps que usam sensores que não ativam precisam manter um bloqueio de ativação para garantir que o sistema não seja suspenso, cancelar o registro dos sensores quando eles não forem necessários ou esperar perder eventos enquanto o SoC estiver no modo de suspensão.
Sensores de ativação
Em oposição aos sensores que não ativam, os sensores de ativação garantem que os dados sejam enviados independentemente do estado do SoC. Enquanto o SoC está ativado, os sensores de ativação se comportam como sensores que não ativam. Quando o SoC está em suspensão, os sensores de ativação precisam ativar o SoC para transmitir eventos. Elas ainda precisam permitir que o SoC entre no modo de suspensão, mas também precisam ativá-lo quando um evento precisa ser informado. Ou seja, o sensor precisa ativar o SoC e entregar os eventos antes que a latência máxima de relatórios tenha decorrido ou que o FIFO de hardware fique cheio. Consulte Como fazer o agrupamento para mais detalhes.
Para garantir que os aplicativos tenham tempo para receber o evento antes que o SoC volte a dormir, o driver precisa manter um "bloqueio de ativação de tempo limite" por 200 milissegundos sempre que um evento é informado. Ou seja, o SoC não pode voltar a ficar suspenso nos 200 milissegundos após uma interrupção de ativação. Esse requisito vai desaparecer em uma versão futura do Android, e precisamos desse bloqueio de ativação de tempo limite até lá.
Como definir sensores de ativação e não ativação?
Até o KitKat, o tipo de sensor determinava se ele era de ativação ou não: a maioria era de sensores que não ativavam o dispositivo, com exceção do sensor de proximidade e do sensor de detecção de movimento significativo.
A partir do L, a especificação de um sensor como de ativação ou não é especificada por uma flag na definição do sensor. A maioria dos sensores pode ser definida por pares de variantes de ativação e não ativação do mesmo sensor. Nesse caso, eles precisam se comportar como dois sensores independentes, sem interagir um com o outro. Consulte Interação para mais detalhes.
A menos que especificado de outra forma na definição do tipo de sensor, é recomendável
implementar um sensor de ativação e um sensor sem ativação para cada tipo de sensor
listado em Tipos de sensores. Em cada definição de tipo de sensor, confira qual sensor (ativação ou não ativação) será retornado por
SensorManager.getDefaultSensor(sensorType). É o sensor
que a maioria dos aplicativos vai usar.