O Android 9 (API nível 28) introduz novos recursos para melhorar o gerenciamento de energia dos dispositivos. Esses mudanças, além de recursos que já estavam presentes em versões anteriores, ajudam para 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 os apps a recursos do dispositivo, como o CPU ou 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 está ativada, o aplica restrições a todos os apps. Esse é um recurso que já existe melhorado 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 Eles ajudam o sistema a priorizar apps solicitações de recursos com base sobre quando e com que frequência os apps foram usados. 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 aplicativo vai para o bucket Ativo se o usuário o estiver utilizando atualmente, 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 quando é executado com frequência, mas não está ativos. Por exemplo, um aplicativo de mídia social que o usuário inicia quase todos os dias é provavelmente estarão 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:
- 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 com a capacidade de executar jobs e acionar alarmes, além de impor um limite 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, um app de hotel que o usuário só funcione enquanto se hospeda nesse hotel pode estar na rara do Google Cloud.
Se um app estiver nesse bucket, o sistema vai impor restrições rígidas a capacidade de executar tarefas, 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 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 eles 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 para apps inativos
atribuídas 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 em qualquer
em que ele pode estar. 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 aplicativo em um único bucket ou outra. 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, é possível que ele nunca seja promovido para a bucket ativo. Você pode reformular seu app para ter essa atividades.
- 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. Em Nesse caso, convém reformular algumas notificações apropriadas para que elas permitam uma resposta do usuário. Para obter algumas diretrizes, consulte a Design de notificações do Material Design padrões.
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 de alta prioridade do FCM é enviar uma notificação ao usuário, então essa situação nunca deve ocorrer. Se você marcar inadequadamente uma mensagem do FCM como sendo de alta prioridade quando ela não é acionada interação do usuário, isso pode causar outras consequências negativas, por exemplo, pode resultar no esgotamento da cota do app, causando Mensagens do FCM a serem tratadas como prioridade normal.
Observação: se o usuário dispensar uma notificação repetidamente, o sistema oferece ao usuário 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 aplicativo 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 compilações do AOSP, o sistema aplica as seguintes restrições:
- O sistema coloca aplicativos no modo de espera de forma mais agressiva, em vez de aguardando o app ficar inativo.
- 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 Android 9, sejam eles os apps são 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 como os recursos de gerenciamento de energia interagem uns com os outros. Você pode usar o Android Debug Bridge a seguir para ativar alguns dos recursos de nuvem.
Comandos do Android Debug Bridge
Você pode usar 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, você poderá desfazer as configurações manuais do dispositivo por este comando:
$ adb shell dumpsys battery reset