Estados de energia do SoC
Os estados de energia do sistema em um chip (SoC) são: ligado, inativo e suspenso. “Ligado” é quando o SoC está em execução. “Idle” é um modo de potência média onde o SoC está ligado, mas não executa nenhuma tarefa. “Suspender” é um modo de baixo consumo de energia em que o SoC não está ligado. O consumo de energia do dispositivo neste modo é geralmente 100 vezes menor do que no modo “Ligado”.
Sensores sem despertar
Sensores sem ativação são sensores que não impedem o SoC de entrar no modo de suspensão e não ativam o SoC para relatar dados. Em particular, os motoristas não estão autorizados a manter wake-locks. É responsabilidade dos aplicativos manter um wake lock parcial caso desejem receber eventos de sensores que não estão ativados enquanto a tela estiver desligada. Enquanto o SoC estiver em modo suspenso, os sensores devem continuar funcionando e gerando eventos, que são colocados em um FIFO de hardware. (Consulte Lote 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 eliminados para acomodar os dados mais recentes. No caso extremo em que o FIFO é inexistente, todos os eventos gerados enquanto o SoC está em modo suspenso são perdidos. Uma exceção é o último evento de cada sensor em mudança: 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 wake lock para garantir que o sistema não entre em suspensão, cancelar o registro dos sensores quando não forem necessários ou esperar perder eventos enquanto o SoC estiver no modo de suspensão.
Sensores de despertar
Ao contrário dos sensores que não são de despertar, os sensores de despertar garantem que os seus dados são entregues independentemente do estado do SoC. Enquanto o SoC está ativado, os sensores de ativação se comportam como sensores não ativados. Quando o SoC está adormecido, os sensores de ativação devem acordá-lo para entregar 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 do relatório tenha decorrido ou que o FIFO do hardware fique cheio. Consulte Lote 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 "wake lock de tempo limite" por 200 milissegundos cada vez que um evento for relatado. Ou seja, o SoC não deve voltar a dormir nos 200 milissegundos seguintes a uma interrupção de despertar. 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 não de despertar era ditado pelo tipo de sensor: a maioria eram sensores de não despertar, 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 de ativação e não ativação do mesmo sensor, caso em que devem se comportar como dois sensores independentes, não interagindo entre si. Consulte Interação para obter mais detalhes.
A menos que especificado de outra forma na definição do tipo de sensor, recomenda-se implementar um sensor de ativação e um sensor de não ativação para cada tipo de sensor listado em Tipos de sensores . Em cada definição de tipo de sensor, veja qual sensor (ativado ou não ativado) será retornado por SensorManager.getDefaultSensor(sensorType) . É o sensor que a maioria dos aplicativos usará.