O Android 9 (API nível 28) introduz novos recursos para melhorar o gerenciamento de energia dos dispositivos. Essas mudanças, além dos recursos já 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 dos apps aos recursos do dispositivo, como a CPU ou a bateria, com base nos padrões de uso do usuário. Esse é um novo recurso Android 9.
- Melhorias na economia de bateria
- Quando a economia de bateria é ativada, o sistema aplica restrições a todos os apps. Esse é um recurso que já existia, mas 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 Intervalos de aplicativos em espera ajudam o sistema a priorizar as solicitações de recursos dos apps com base na frequência e no uso recente deles. Com base no uso do app padrões, cada app é colocado em um dos 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 é inserido no intervalo de ativos se o usuário o estiver usando no momento, 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 nesse bucket, o sistema não vai aplicar restrições as tarefas, os alarmes ou as mensagens do FCM.
- Grupo de trabalho
Um app vai para o bucket do conjunto de trabalho se for executado com frequência, mas não estiver 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 o conjunto de trabalho se forem 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 mais detalhes, consulte Restrições do gerenciamento de energia:
- Frequentes
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 no intervalo de frequentes, o sistema vai impor restrições mais rígidas à capacidade de executar jobs e acionar alarmes, além de impor um limite para mensagens FCM de alta prioridade. Para mais detalhes, consulte Restrições do gerenciamento de energia:
- Rara
Um aplicativo é inserido no intervalo de raros se não for usado com frequência. Por exemplo, o app de um hotel que o usuário só executa enquanto está hospedado nesse hotel pode estar no bucket raro.
Se um app estiver no intervalo de dados, o sistema impõe 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 aplicativo a um bucket prioritário e reatribui os conforme necessário. O sistema pode depender de um app pré-carregado que usa máquinas para determinar a probabilidade de cada é usado e atribui os apps aos buckets apropriados. Se o sistema aplicativo não estiver presente em um dispositivo, o sistema padroniza para classificar aplicativos com base em há quanto tempo foram usados. Os apps mais ativos são atribuídos a buckets que dar mais prioridade aos apps, mais recursos do sistema disponíveis para o app. Especificamente, o bucket determina com que frequência os jobs do app são executados, com que frequência o app pode ser acionado alarmes e com que frequência o app pode receber dados de prioridade alta do Firebase Cloud Mensagens (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. Você não deve tentar influenciar em qual bucket seu app
está atribuída. 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á segue as práticas recomendadas Soneca e App em espera, não será difícil lidar com os novos recursos de gerenciamento de energia. No entanto, o comportamento de alguns 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 todos os dispositivos o fabricante poderia optar por criar o próprio app de agrupamento por classes 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 práticas, os usuários não vão poder 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 do Material Design (link em inglês).
Da mesma forma, se o aplicativo não mostrar uma notificação ao receber uma mensagem de alta prioridade do FCM, não dará ao usuário a chance de interagir com o aplicativo e promovê-lo para bucket ativo. Na verdade, o único uso pretendido para mensagens FCM de alta prioridade é enviar uma notificação ao usuário. Portanto, essa situação nunca deve ocorrer. Se você marcar incorretamente uma mensagem FCM como de alta prioridade quando ela não aciona uma interação do usuário, isso pode ter outras consequências negativas. Por exemplo, isso pode fazer com que seu app esgote a cota, fazendo com que mensagens FCM realmente urgentes sejam tratadas como prioridade normal.
Observação: se o usuário dispensar várias vezes uma notificação, o sistema vai oferecer 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 estiverem divididos entre vários pacotes, eles poderão estar buckets diferentes e, assim, ter níveis de acesso distintos. Você não pode deixar de testar esses aplicativos com os pacotes atribuídos a vários buckets para garantir que os 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 de 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 da API de destino nível
- 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 total detalhes, consulte a página que descreve o gerenciamento de energia restrições.
Como sempre, é recomendado testar seu app enquanto a "Economia de bateria" está ativa. Você pode ativar a economia de bateria manualmente nas Configurações > Bateria Economizador.
Testar e resolver problemas.
Os novos recursos de gerenciamento de energia afetam todos os apps executados em dispositivos com Android 9, mesmo que esses apps sejam direcionados ao Android 9. É importante garantir que seu app se comporte 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 da Android Debug Bridge para ativar e desativar alguns dos 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 intervalo 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 intervalo 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