Gerenciamento de energia

O Android 9 (API nível 28) introduz novos recursos para melhorar o gerenciamento de energia dos dispositivos. Essas mudanças, junto com recursos que já estavam presentes em versões anteriores, ajudam a garantir que os recursos do sistema sejam fornecidos aos apps que mais precisam deles.

Os recursos de gerenciamento de energia se encaixam em duas categorias:

Buckets do App em espera
O sistema limita o acesso dos apps a recursos do dispositivo, como a CPU ou a bateria, com base nos padrões de uso do usuário. Esse é um novo recurso do Android 9.
Melhorias na Economia de bateria
Quando a Economia de bateria está ativada, o sistema aplica restrições a todos os apps. Esse é um recurso existente que foi aprimorado com o Android 9.

Buckets do App em espera

O Android 9 introduz um novo recurso de gerenciamento de bateria, os Intervalos de aplicativos em espera Esse recurso ajuda o sistema a priorizar solicitações de apps para recursos com base no modo e na frequência com que os aplicativos foram usados. Com base nos padrões de uso, cada app é colocado em um de cinco buckets de prioridade. O sistema limita os recursos do dispositivo disponíveis para cada app com base no bucket em que o app está.

Os cinco intervalos priorizam aplicativos em grupos com base nas seguintes características:

Ativo

Um app vai ser incluído no bucket ativo se estiver sendo usado pelo usuário, por exemplo:

  • O app iniciou uma atividade.
  • O app está executando um serviço no primeiro plano.
  • O app tem um adaptador de sincronização associado a um provedor de conteúdo usado por um app em primeiro plano
  • O usuário clica em uma notificação do app.

Se um app estiver no bucket ativo, o sistema não vai colocar restrições para jobs, alarmes ou mensagens do FCM do app.

Conjunto de trabalho

Um app vai para o bucket do conjunto de trabalho quando é executado com frequência, mas não está ativo no momento. Por exemplo, um app de mídia social que o usuário inicia quase todos os dias provavelmente estará no conjunto de trabalho. Os apps também são promovidos para esse bucket quando são usados indiretamente.

Quando um app está no bucket de conjunto de trabalho, o sistema impõe restrições moderadas à capacidade de executar jobs e acionar alarmes. Para saber detalhes, consulte Restrições de gerenciamento de energia.

Frequente

Um app vai para o bucket frequente quando é usado com regularidade, mas não necessariamente todos os dias. Por exemplo, um app de monitoramento de treinos que o usuário executa na academia pode estar no bucket frequente.

Se um app estiver nesse bucket, o sistema vai impor restrições mais rígidas à capacidade de executar jobs e acionar alarmes e também impõe um limite para mensagens de alta prioridade do FCM. Para saber detalhes, consulte Restrições de gerenciamento de energia.

Raramente

Um aplicativo é inserido no intervalo de raros se não for usado com frequência. Por exemplo, um app de hotel que o usuário executa apenas enquanto se hospeda nesse local pode estar no bucket raro.

Se um app estiver nesse bucket, o sistema vai impor restrições rígidas à capacidade de executar jobs, acionar alarmes e receber mensagens de alta prioridade do FCM. O sistema também limita a capacidade do app de se conectar à Internet. Para detalhes, consulte Restrições do gerenciamento de energia.

Nunca

Aplicativos que foram instalados mas nunca executados são inseridos no intervalo de nunca. O sistema impõe restrições bastante severas a esses aplicativos.

O sistema atribui dinamicamente cada app a um bucket de prioridade e os reatribui conforme necessário. O sistema pode se basear em um app pré-carregado que usa machine learning para determinar a probabilidade de uso de cada app e atribui apps aos buckets apropriados. Se o app do sistema não estiver presente em um dispositivo, o padrão será classificar os apps com base no tempo em que eles foram usados por padrão. Apps mais ativos são atribuídos a buckets que atribuem maior prioridade a eles, disponibilizando mais recursos do sistema. Especificamente, o bucket determina a frequência de execução dos jobs do app, a frequência com que o app pode acionar alarmes e a frequência com que o app pode receber mensagens de alta prioridade do Firebase Cloud Messaging (FCM). Essas restrições se aplicam somente enquanto o dispositivo está usando a energia da bateria. O sistema não impõe essas restrições a apps enquanto o dispositivo está carregando.

Cada fabricante pode definir critérios próprios de atribuição de apps inativos a buckets. Não tente influenciar para qual bucket seu app é atribuído. Em vez disso, concentre-se em garantir que o app se comporte bem, independente do bucket. Seu app pode descobrir em qual bucket está no momento chamando o novo método UsageStatsManager.getAppStandbyBucket().

Práticas recomendadas

Se o app já estiver seguindo as práticas recomendadas para Soneca e App em espera, processar os novos recursos de gerenciamento de energia não será difícil. No entanto, alguns comportamentos de apps que antes funcionavam bem agora podem causar problemas.

  • Não tente manipular o sistema para colocar seu app em um bucket ou outro. Os métodos de agrupamento por classes do sistema podem mudar, e cada fabricante de dispositivos pode optar por criar um app de agrupamento com o próprio algoritmo. Em vez disso, garanta que o app se comporte de forma correta, independente do bucket.
  • Se um app não tiver uma atividade de tela de início, ele nunca será promovido para o bucket ativo. Você pode reformular seu app para ter essa atividade.
  • Se as notificações do app não forem acionáveis, os usuários não poderão acionar a promoção do app para o bucket ativo interagindo com as notificações. Nesse caso, reformule algumas notificações apropriadas para que elas permitam uma resposta do usuário. Para conferir algumas diretrizes, consulte os Padrões de design de notificações (link em inglês) do Material Design.
  • Da mesma forma, se o app não mostrar uma notificação ao receber uma mensagem de alta prioridade do FCM, o usuário não poderá interagir com o app nem promovê-lo para o bucket ativo. Na verdade, o único uso pretendido para mensagens de alta prioridade do FCM é enviar uma notificação ao usuário. Portanto, essa situação nunca deve ocorrer. Se você marcar incorretamente uma mensagem do FCM como de alta prioridade quando ela não aciona a interação do usuário, isso pode causar outras consequências negativas. Por exemplo, o app pode esgotar a cota, fazendo com que mensagens do FCM realmente urgentes sejam tratadas como prioridade normal.

    Observação:se o usuário dispensar uma notificação repetidamente, o sistema vai oferecer a ele a opção de bloquear essa notificação no futuro. Não envie spam ao usuário com notificações apenas para tentar manter seu app no bucket ativo.

  • Se os apps forem divididos em vários pacotes, esses pacotes poderão estar em buckets diferentes e, assim, ter diferentes níveis de acesso. Teste esses apps com os pacotes atribuídos a vários buckets para verificar se o app se comporta corretamente.

Melhorias na Economia de bateria

O Android 9 apresenta diversas melhorias no modo de economia de bateria. O fabricante do dispositivo determina as restrições precisas impostas. Por exemplo, em builds do AOSP, o sistema aplica as seguintes restrições:

  • O sistema coloca os apps no modo em espera de forma mais agressiva, em vez de esperar que eles fiquem inativos.
  • Os limites de execução em segundo plano se aplicam a todos os apps, independente do nível desejado da API.
  • Os serviços de localização podem ser desativados quando a tela está desligada.
  • Os apps em segundo plano não têm acesso à rede.

Além disso, há outras otimizações de energia específicas a dispositivos. Para mais detalhes, consulte a página que descreve as restrições de gerenciamento de energia.

Como sempre, é recomendado testar seu app enquanto a "Economia de bateria" está ativa. É possível ativar a Economia de bateria manualmente na tela Configurações > Economia de bateria do dispositivo.

Testar e resolver problemas

Os novos recursos de gerenciamento de energia afetam todos os apps executados em dispositivos Android 9, mesmo que os apps não sejam direcionados ao Android 9. É importante conferir se o app se comporta corretamente nesses dispositivos.

Teste os principais casos de uso do app em diversas condições para ver como os recursos de gerenciamento de energia interagem entre si. Use os comandos do Android Debug Bridge para ativar e desativar alguns recursos.

Comandos do Android Debug Bridge

Use os comandos do shell do Android Debug Bridge para testar vários recursos de gerenciamento de energia.

Para mais informações sobre como usar o adb para colocar o dispositivo no modo Soneca, consulte Testes com os recursos Soneca e App em espera.

Buckets do App em espera

Use o ADB para atribuir manualmente seu app a um intervalo do "App em espera". Para mudar o bucket de um app, use o seguinte comando:

$ adb shell am set-standby-bucket packagename active|working_set|frequent|rare

Você também pode usar esse comando para definir vários pacotes de uma vez:

$ adb shell am set-standby-bucket package1 bucket1 package2 bucket2...

Para verificar em qual intervalo seu aplicativo se encontra, execute

$ adb shell am get-standby-bucket [packagename]

Se você não passar um parâmetro packagename, o comando listará os buckets de todos os apps. Um app também pode descobrir o próprio bucket durante a execução chamando o novo método UsageStatsManager.getAppStandbyBucket().

Economia de bateria

Há vários comandos para testar como seu app se comporta em condições de pouca bateria.

Para simular um dispositivo desconectado da tomada, use o comando

$ adb shell dumpsys battery unplug

Para testar como o dispositivo se comporta em condições de pouca bateria, use este comando:

$ adb shell settings put global low_power 1

Depois de concluir o teste, é possível desfazer as configurações manuais do dispositivo com este comando:

$ adb shell dumpsys battery reset