Estados de energia do SoC
Os estados de energia do sistema em um chip (SoC) são: ligado, ocioso e suspenso. “On” é quando o SoC está em execução. “Idle” é um modo de energia média em que o SoC é alimentado, mas não executa nenhuma tarefa. “Suspender” é um modo de baixo consumo de energia em que o SoC não é alimentado. O consumo de energia do dispositivo neste modo é geralmente 100 vezes menor do que no modo “On”.
Sensores que não despertam
Sensores sem ativação são sensores que não impedem que o SoC entre no modo de suspensão e não despertam o SoC para relatar dados. Em particular, os drivers não têm permissão para realizar wake-locks. É responsabilidade dos aplicativos manter um wake lock parcial caso desejem receber eventos de sensores que não despertam enquanto a tela está desligada. Enquanto o SoC estiver em modo de suspensão, os sensores devem continuar funcionando e gerando eventos, que são colocados em uma FIFO de hardware. (Consulte Batching para obter mais detalhes.) Os eventos no FIFO são entregues aos aplicativos quando o SoC é ativado. Se o FIFO for muito pequeno para armazenar todos os eventos, os eventos mais antigos serão perdidos; os dados mais antigos são descartados para acomodar os dados mais recentes. No caso extremo em que o FIFO é inexistente, todos os eventos gerados enquanto o SoC está em modo de suspensão são perdidos. Uma exceção é o último evento de cada sensor on-change: o último evento deve ser salvo fora do FIFO para que não possa ser perdido.
Assim que o SoC sai do modo de suspensão, todos os eventos do FIFO são relatados e as operações são retomadas normalmente.
Os aplicativos que usam sensores sem ativação devem manter um bloqueio de ativação para garantir que o sistema não seja suspenso, cancelar o registro dos sensores quando eles não precisarem deles ou esperar perder eventos enquanto o SoC estiver no modo de suspensão.
Sensores de despertar
Em oposição aos sensores sem despertar, os sensores de despertar garantem que seus dados sejam entregues independentemente do estado do SoC. Enquanto o SoC está ativado, os sensores de ativação se comportam como sensores sem ativação. Quando o SoC está adormecido, os sensores de ativação devem ativar o SoC para fornecer eventos. Eles ainda devem deixar o SoC entrar no modo de suspensão, mas também devem ativá-lo quando um evento precisar ser relatado. Ou seja, o sensor deve ativar o SoC e entregar os eventos antes que a latência máxima de relatório tenha decorrido ou o FIFO de hardware fique cheio. Consulte Lotes para obter mais detalhes.
Para garantir que os aplicativos tenham tempo para receber o evento antes que o SoC volte a dormir, o driver deve manter um "timeout wake lock" por 200 milissegundos cada vez que um evento estiver sendo relatado. Ou seja, o SoC não deve voltar a dormir nos 200 milissegundos após uma interrupção de ativação. Esse requisito desaparecerá em uma versão futura do Android e precisamos desse wake lock de tempo limite até então.
Como definir sensores de despertar e não despertar?
Até o KitKat, se um sensor era um sensor de despertar ou um sensor não despertador era ditado pelo tipo de sensor: a maioria eram sensores não despertadores, com exceção do sensor de proximidade e do detector de movimento significativo .
Começando em L, se um determinado sensor é um sensor de despertar ou não, é especificado por um sinalizador na definição do sensor. A maioria dos sensores pode ser definida por pares de variantes wake-up e non-wake-up do mesmo sensor, caso em que eles devem se comportar como dois sensores independentes, não interagindo um com o outro. Consulte Interação para obter 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 de não ativação para cada tipo de sensor listado em Tipos de sensor . Em cada definição de tipo de sensor, veja qual sensor (despertar ou não despertar) será retornado por SensorManager.getDefaultSensor(sensorType) . É o sensor que a maioria dos aplicativos usará.