O Android 9 (API nível 28) introduz novos recursos para melhorar o gerenciamento de energia dos dispositivos. Essas mudanças, junto com os recursos que já estavam presentes nas 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 de 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 no Android 9.
Buckets do App em espera
O Android 9 introduz um novo recurso de gerenciamento de bateria, os Intervalos de aplicativos em espera Os Buckets do App em espera ajudam o sistema a priorizar solicitações de apps para recursos com base no modo e na frequência com que os aplicativos são 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:
- Ativas
Um app é considerado no bucket ativo quando é 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 esse bucket 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, além de impor 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 FCM de alta prioridade. 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 aplicativo e atribui apps aos buckets apropriados. Se o app do sistema não estiver presente em um dispositivo, o padrão vai ser classificar os apps com base em quando eles foram usados. Apps mais ativos são atribuídos a buckets que oferecem maior prioridade, disponibilizando mais recursos do sistema para eles. Especificamente, o bucket determina a frequência com que os jobs do app são executados, a frequência com que o app pode acionar alarmes e com que frequência o app pode receber mensagens do Firebase Cloud Messaging (FCM) de alta prioridade. 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á está 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, o comportamento de alguns apps que antes funcionavam bem agora pode causar problemas.
- Não tente manipular o sistema para colocar seu app em um bucket ou outro. Os métodos de agrupamento 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 adequadas para que elas permitam uma resposta do usuário. Para conferir algumas diretrizes, consulte os Padrões de design de notificações 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 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 realmente urgentes do FCM sejam tratadas como prioridade normal.
Observação:se o usuário dispensar uma notificação repetidamente, o sistema oferecerá a opção de bloquear essa notificação no futuro. Não envie spam ao usuário apenas para tentar manter seu app no bucket ativo.
Se os apps forem divididos em vários pacotes, esses pacotes podem estar em buckets diferentes e, portanto, ter níveis de acesso distintos. 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, independentemente 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 detalhes completos, 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 sejam direcionados a essa versão. É importante garantir que o app se comporte corretamente nesses dispositivos.
Teste os principais casos de uso do seu 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 alterar 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