Otimizar para os modos Soneca e App em espera

O Android tem dois recursos de economia de energia que prolongam a duração da bateria para os usuários ao controlar como os apps se comportam quando um dispositivo não está conectado a uma fonte de energia: o modo Soneca e o modo App em espera. O recurso Soneca reduz o consumo da bateria, adiando a atividade de CPU e de rede em segundo plano para apps quando o dispositivo não é usado por longos períodos. O App em espera adia a atividade de rede em segundo plano para apps sem atividade recente do usuário.

Enquanto o dispositivo está no modo Soneca, o acesso de apps a determinados recursos que consomem muita bateria é adiado até a janela de manutenção. As restrições específicas estão listadas em Restrições do gerenciamento de energia.

Os recursos Soneca e App em espera controlam o comportamento de todos os apps em execução no Android 6.0 ou mais recente, independentemente se são direcionados especificamente para a API de nível 23 ou não. Para garantir a melhor experiência para os usuários, teste seu app nos modos Soneca e App em espera e faça os ajustes necessários no código. As seções a seguir fornecem detalhes.

Entender o modo Soneca

Se um usuário deixa um dispositivo desconectado e parado por um período de tempo, com a tela apagada, o dispositivo entra em modo Soneca. No modo Soneca, o sistema tenta economizar bateria, restringindo o acesso de apps à rede e a serviços com uso intenso da CPU. Ele também impede que apps acessem a rede e adia jobs, sincronizações e alarmes padrão.

Periodicamente, o sistema sai da Soneca por um breve período para permitir que os apps concluam as atividades adiadas. Durante essa janela de manutenção, o sistema executa todos os trabalhos, sincronizações e alarmes pendentes, e permite que os apps acessem a rede.

Figura 1. O Doze oferece uma janela de manutenção recorrente para que os apps usem a rede e realizem atividades pendentes.

Quando a janela de manutenção é concluída, o sistema entra novamente no modo Soneca, Suspendendo o acesso à rede e adiando trabalhos, sincronizações e alarmes. Com o tempo, o sistema programa janelas de manutenção com menos frequência, ajudando a reduzir o consumo da bateria em casos de inatividade mais longa, quando o dispositivo não está carregando.

Quando o usuário ativa o dispositivo, movendo-o, ligando a tela ou conectando um carregador, o sistema sai do Soneca e todos os apps retomam a atividade normal.

Restrições do recurso Soneca

O sistema aplica as seguintes restrições aos apps durante a Soneca:

• Suspende o acesso à rede.
• Ignora wake locks.
• Adia alarmes AlarmManager padrão, incluindo setExact() e setWindow(), até a próxima janela de manutenção.
  • Se você precisar definir alarmes que disparam durante o "Soneca", use setAndAllowWhileIdle() ou setExactAndAllowWhileIdle().
  • Alarmes programados com setAlarmClock() continuam a disparar normalmente. O sistema sai do modo Soneca pouco antes desses alarmes dispararem.
• Não realiza buscas por Wi-Fi.
• Não permite a execução de adaptadores de sincronização.
• Não permite que JobScheduler seja executado.
  WorkManager usa JobScheduler internamente, então as tarefas WorkManager não são executadas.

Lista de verificação do Soneca

• Se possível, use o Firebase Cloud Messaging (FCM) para mensagens downstream.
• Se seus usuários precisarem receber uma notificação imediatamente, use uma mensagem de alta prioridade do FCM. Use apenas a prioridade alta para mensagens que resultam em uma notificação. Para mais orientações, consulte a documentação do FCM sobre prioridades de mensagens para Android.
• Forneça informações suficientes dentro do payload da mensagem inicial para que o acesso subsequente à rede não seja necessário.
• Defina alarmes críticos com setAndAllowWhileIdle() e setExactAndAllowWhileIdle().
• Teste seu app no modo Soneca.

Adaptar seu app ao recurso Soneca

A Soneca pode afetar apps de forma diferente, dependendo dos recursos que oferecem e dos serviços que usam. Muitos apps funcionam normalmente durante os ciclos do Soneca, sem modificações. Em alguns casos, você precisa otimizar a maneira como o app gerencia rede, alarmes, trabalhos e sincronizações. Os apps precisam ser capazes de gerenciar atividades de modo eficiente durante cada janela de manutenção.

Para ajudar a programar alarmes, você pode usar dois métodos AlarmManager: setAndAllowWhileIdle() e setExactAndAllowWhileIdle(). Com esses métodos, você pode definir alarmes que disparam mesmo se o dispositivo estiver em Soneca.

Observação:nem setAndAllowWhileIdle() nem setExactAndAllowWhileIdle() podem disparar alarmes mais de uma vez a cada nove minutos por app.

A restrição do "Soneca" sobre o acesso à rede provavelmente também afetará seu app, principalmente se ele depender de mensagens em tempo real, como convites ou notificações. Se o app requer uma conexão persistente com a rede para receber mensagens, use o Firebase Cloud Messaging (FCM), se possível.

Para confirmar que seu app se comporta como esperado com a Soneca, você pode usar comandos adb para forçar o sistema a entrar e sair da Soneca e observar o comportamento do app. Para mais detalhes, consulte Testar com os recursos Soneca e App em espera.

Entender o App em espera

O App em espera permite que o sistema determine se um app está ocioso quando o usuário não o está usando ativamente. O sistema determina isso quando o usuário não toca no app por um determinado período e nenhuma das condições a seguir se aplica:

• O usuário inicia o aplicativo explicitamente.
• O app tem um processo atualmente em primeiro plano, seja uma atividade ou serviço de primeiro plano ou que esteja em uso por outra atividade ou serviço de primeiro plano.
  Observação:use apenas um serviço em primeiro plano para tarefas que o usuário espera que o sistema execute imediatamente ou sem interrupção. Esses casos incluem o upload de uma foto para as redes sociais ou a reprodução de música mesmo que o app player de música não esteja em primeiro plano. Não inicie um serviço em primeiro plano apenas para impedir que o sistema determine que o app está ocioso.
• O app gera uma notificação que os usuários veem na tela de bloqueio ou na bandeja de notificações.

Quando o usuário conecta o dispositivo a uma fonte de alimentação, o sistema libera apps do estado de espera, permitindo que eles acessem livremente a rede e executem todos os trabalhos e sincronizações pendentes. Se o dispositivo permanece ocioso por longos períodos, o sistema permite que os apps ociosos acessem a rede aproximadamente uma vez por dia.

Usar o FCM para interagir com o app enquanto o dispositivo está ocioso

O Firebase Cloud Messaging (FCM) é um serviço de nuvem para dispositivos que permite oferecer suporte a mensagens downstream em tempo real entre serviços de back-end e apps em dispositivos Android. O FCM oferece uma conexão única e persistente com a nuvem. Todos os apps que precisam de mensagens em tempo real podem compartilhar essa conexão. Essa conexão compartilhada otimiza significativamente o consumo da bateria, tornando desnecessário que vários apps mantenham as próprias conexões persistentes separadas, o que pode esgotar a bateria rapidamente. Por esse motivo, se o app requer integração de mensagens com um serviço de back-end, é altamente recomendável que você use o FCM, se possível, em vez de manter sua própria conexão de rede persistente.

O FCM é otimizado para funcionar com os modos ociosos dos modos Soneca e App em espera. As mensagens de alta prioridade do FCM permitem que você ative seu app para interagir com o usuário. Em Soneca ou no modo App em espera, o sistema envia a mensagem e dá ao app acesso temporário a serviços de rede e wakelocks parciais, depois retorna o dispositivo ou app ao estado ocioso. Para notificações visíveis ao usuário e urgentes, considere usar mensagens de alta prioridade para ativar a entrega no modo Soneca. Mensagens de alta prioridade podem resultar em notificações. Consulte as orientações do FCM sobre mensagens de alta prioridade para mais informações.

Para mensagens que não resultam em notificações, como manter o conteúdo do app atualizado em segundo plano ou iniciar sincronizações de dados, use mensagens do FCM de prioridade normal. As mensagens de prioridade normal serão entregues imediatamente se o dispositivo não estiver no modo Soneca. Se o dispositivo estiver no modo Soneca, eles serão entregues durante as janelas de manutenção periodicas do modo Soneca ou assim que o usuário ativar o dispositivo.

Como prática recomendada geral, se o app exigir mensagens downstream, use o FCM. Se o app já usa o FCM, verifique se ele usa mensagens de alta prioridade apenas para mensagens que geram notificações para o usuário.

Compatibilidade com outros casos de uso

Quase todos os apps podem oferecer suporte ao recurso Soneca ao gerenciar conectividade de rede, alarmes, trabalhos e sincronizações e usar mensagens FCM. Para um conjunto restrito de casos de uso, isso pode ser insuficiente. Para esses casos, o sistema fornece uma lista configurável de apps que são parcialmente isentos das otimizações do modo Soneca e do App em espera.

Um app parcialmente isento pode usar a rede e manter wake locks parciais durante a Soneca e o App em espera. No entanto, outras restrições ainda se aplicam ao app, da mesma forma que ocorre com outros apps. Por exemplo, os jobs e as sincronizações do app são adiados no nível 23 da API e anteriores, e os alarmes AlarmManager regulares não são acionados. Um app pode verificar se está na lista de isenção chamando isIgnoringBatteryOptimizations().

Os usuários podem configurar manualmente a lista de apps isentos em Configurações > Bateria > Otimização da bateria. Como alternativa, o sistema oferece maneiras para os apps pedirem que os usuários os isentem:

• A maioria dos apps pode invocar uma intent que contém a ACTION_IGNORE_BATTERY_OPTIMIZATION_SETTINGS.
• Apps que atendem a um caso de uso aceitável podem invocar uma intent que contém a ação da intent ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS para permitir que o usuário adicione o app diretamente à lista de isenções, sem acessar as configurações do sistema.

Observação:as políticas do Google Play proíbem apps de solicitar isenção direta dos recursos de gerenciamento de energia (Soneca e App em espera) no Android 6.0 e versões mais recentes, a menos que a função principal do app seja afetada negativamente.

Um app pode verificar se está na lista de isenções chamando isIgnoringBatteryOptimizations().

Testar com os recursos Soneca e App em espera

Para ajudar a garantir uma ótima experiência para seus usuários, teste seu app totalmente nos modos Soneca e App em espera.

Testar o app com a Soneca

Para testar o modo Soneca, faça o seguinte:

1. Configure um dispositivo de hardware ou dispositivo virtual com Android 6.0 (API de nível 23) ou sistema de imagem mais recente.
2. Conecte o dispositivo à máquina de desenvolvimento e instale o aplicativo.
3. Execute o aplicativo e deixe-o ativo.
4. Force o sistema a entrar no modo ocioso executando o seguinte comando:

       $ adb shell dumpsys deviceidle force-idle
       

5. Quando estiver pronto, saia do modo ocioso executando o seguinte comando:

       $ adb shell dumpsys deviceidle unforce
       

6. Reative o dispositivo executando o seguinte comando:

       $ adb shell dumpsys battery reset
       

7. Observe o comportamento do seu app depois de reativar o dispositivo. Certifique-se de que o app se recupera normalmente quando o dispositivo sai do modo Soneca.

Testar o app com o App em espera

Para testar o modo App em espera com seu app, faça o seguinte:

1. Configure um dispositivo de hardware ou dispositivo virtual com um Android 6.0 (API de nível 23) ou sistema de imagem posterior.
2. Conecte o dispositivo à máquina de desenvolvimento e instale o aplicativo.
3. Execute o aplicativo e deixe-o ativo.
4. Execute os seguintes comandos para forçar o app a entrar no modo "App em espera":

       $ adb shell dumpsys battery unplug
       $ adb shell am set-inactive <packageName> true
       

5. Simule a ativação do app usando os seguintes comandos:

       $ adb shell am set-inactive <packageName> false
       $ adb shell am get-inactive <packageName>
       

6. Observe o comportamento do seu app depois de despertá-lo. Verifique se o app se recupera corretamente do modo de espera. Em particular, verifique se as notificações do app e os jobs em segundo plano funcionam conforme o esperado.

Casos de uso aceitáveis para isenção

A tabela abaixo destaca vários casos de uso e se é aceitável que os apps usem a ação da intent ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS nessas situações. Em geral, seu app não atende a essas exceções, a menos que os recursos "Soneca" ou "App em espera" interrompam a função principal do app ou que haja uma razão técnica pela qual seu app não pode usar mensagens de alta prioridade do FCM.

Para mais informações, consulte Suporte para outros casos de uso.

Tipo	Caso de uso	Pode usar o FCM?	Isenção aceitável?	Observações
Mensagens instantâneas, bate-papo ou app de chamada.	Requer entrega de mensagens em tempo real para usuários enquanto o dispositivo está em Soneca ou o app está no modo Aplicativo em espera.	Sim, usando o FCM.	Não aceitável	Use as mensagens de alta prioridade do FCM para ativar o app e acessar a rede.
		Sim, mas não está usando mensagens FCM de alta prioridade.
Mensagens instantâneas, chat ou app de chamada; apps empresariais de VOIP.		Não, não é possível usar o FCM devido à dependência técnica de outro serviço de mensagens, ou os recursos Soneca e App em espera interrompem a função principal do app.	Aceitável
App Emergência.	Apps que protegem os usuários e as famílias.	Se aplicável.	Aceitável
App de automação de tarefas.	A função principal do app é programar ações automatizadas, como para mensagens instantâneas, chamadas de voz ou novos gerenciamentos de fotos.	Se aplicável.	Aceitável
App complementar de dispositivo periférico.	A função principal do app é manter uma conexão persistente com o dispositivo periférico para que ele tenha acesso à Internet.	Se aplicável.	Aceitável
	O app só precisa se conectar a um dispositivo periférico periodicamente para sincronizar ou só precisa se conectar a dispositivos, como fones de ouvido sem fio, conectados por perfis de Bluetooth padrão.	Se aplicável.	Não aceitável