Buckets do App em espera

O Android 9 (API de nível 28) e versões mais recentes oferecem suporte para os buckets do App 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 apps são usados. De acordo com os 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á.

Buckets de prioridade

O sistema atribui dinamicamente cada app a um bucket de prioridade, reatribuindo-os conforme necessário. O sistema pode se basear em um app pré-carregado que usa aprendizado de máquina para determinar a probabilidade de uso de cada app e atribui apps aos buckets adequados. Se o app do sistema não estiver presente em um dispositivo, o comportamento padrão será classificar apps de acordo com a data em que eles foram usados. Os apps mais ativos são atribuídos a buckets que dão maior prioridade aos apps, disponibilizando mais recursos do sistema para eles. Em particular, o bucket determina com que frequência os jobs do app serão executados e com que frequência o app pode acionar alarmes. Essas restrições são válidas 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.

Observação: 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 verificar se o app se comporta bem, independentemente do bucket. Seu app pode descobrir em que bloco está localizado atualmente chamando UsageStatsManager.getAppStandbyBucket().

Os buckets são:

  1. Ativo: o app está sendo usado ou foi usado recentemente.
  2. Grupo de trabalho: o app está em uso regular.
  3. Frequente: o app costuma ser usado, mas não todos os dias.
  4. Raro: o app não é usado com frequência.
  5. Restrito: o app consome uma grande quantidade de recursos do sistema ou pode apresentar comportamento indesejado.

Além disso, há o bucket especial Nunca para apps que foram instalados, mas nunca foram executados. O sistema impõe restrições severas a esses apps.

Observação: os apps que estão na lista de isenções de Soneca são isentos das restrições baseadas nos buckets do App em espera.

Observação: as descrições a seguir referem-se ao caso não preditivo. Por outro lado, quando a previsão usa aprendizado de máquina para prever um comportamento, os buckets são escolhidos antes das próximas ações do usuário, não com base nas datas de uso. Por exemplo, um app usado recentemente pode acabar no bucket Raro porque o aprendizado de máquina prevê que o app não será usado por várias horas.

Ativo

Um app passa para o bucket Ativo quando ele está sendo usado pelo usuário ou se foi usado muito recentemente. 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 no 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 ou alarmes do app.

A interação do usuário coloca o app no bucket ativo

No Android 9 (nível 28 da API) e versões mais recentes, quando o usuário interage com um aplicativo de determinadas maneiras, o sistema coloca o app temporariamente no bucket ativo". Passado algum tempo depois que o usuário para de interagir com ele, o sistema coloca o app em outro bucket, de acordo com o histórico de uso.

Confira alguns exemplos de interações que acionam esse comportamento do sistema:

  • O usuário tocou em uma notificação enviada pelo app.

  • O usuário interagiu com um serviço em primeiro plano no app ao pressionar um botão de mídia.

  • O usuário se conectou ao app ao interagir com o Android Automotive OS, em que o app usa um serviço em primeiro plano ou CONNECTION_TYPE_PROJECTION.

Grupo de trabalho

Um app vai para o bucket Grupo de trabalho se é 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 Grupo de trabalho. Os apps também são promovidos para esse bucket quando são usados indiretamente.

Quando um app está no bucket Grupo 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 atividades físicas 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. Para saber detalhes, consulte Restrições de gerenciamento de energia.

Raro

Um app vai para o bucket Raro quando não é 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 nesse bucket, o sistema vai impor restrições rígidas à capacidade de executar jobs e acionar alarmes. O sistema também limita a capacidade do app de se conectar à Internet. Para saber detalhes, consulte Restrições de gerenciamento de energia.

Restrito

Esse bucket, adicionado no Android 12 (nível 31 da API), tem a prioridade mais baixa (e as restrições mais altas) de todos os buckets. O sistema considera o comportamento do app, como a frequência com que o usuário interage com ele, para decidir se ele vai ser colocado no bucket restrito.

No Android 13 (nível 33 da API) e versões mais recentes, a menos em casos em que há uma isenção, o sistema coloca o app no bucket restrito nas situações abaixo:

  • O usuário não interagiu com o app por um número específico de dias. No Android 12 (nível 31 da API) e no 12L (nível 32 da API), o número de dias é 45. No Android 13, esse número foi reduzido para 8.

  • O app invoca um número excessivo de transmissões ou vinculações em um período de 24 horas.

Se o sistema colocar o app no bucket restrito, as restrições abaixo vão ser aplicadas:

  • É possível executar jobs uma vez por dia, em uma sessão em lote de 10 minutos. Durante essa sessão, o sistema agrupa os jobs do app com os de outros apps.
    • Os jobs restritos não são executados sozinhos. É necessário que haja pelo menos outro job em execução/pendente ao mesmo tempo, o que pode incluir qualquer outro job.
  • O app pode executar menos jobs priorizados em comparação a quando o sistema coloca o app em um bucket menos restritivo.
  • Seu app pode invocar um alarme por dia. Ele pode ser um alarme exato ou um alarme impreciso.

Apps isentos do bucket restrito

Os tipos de app abaixo estão isentos de serem colocados no bucket restrito para apps em espera e ignoram os indicadores de inatividade, mesmo no Android 12 e versões mais recentes:

Práticas recomendadas

Caso seu app já siga as práticas recomendadas para modo Soneca e o App em espera, você não terá dificuldades para lidar com os novos recursos de gerenciamento de energia. No entanto, o comportamento de alguns apps que anteriormente 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 por classes do sistema podem mudar, e o fabricante de cada dispositivo pode optar por criar um app de agrupamento com o próprio algoritmo. Em vez disso, verifique se o seu app se comporta de forma correta, independentemente 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 (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 Firebase Cloud Messaging (FCM), o usuário não vai poder interagir com o app nem o promover para o bucket ativo. Na verdade, único uso pretendido para mensagens de alta prioridade do FCM é enviar uma notificação ao usuário. Portanto, essa situação nunca deve ocorrer. No 12L (nível 32 da API) e versões anteriores, se você marcar incorretamente uma mensagem do FCM como sendo de alta prioridade quando ela não aciona a interação do usuário, a prioridade de mensagens futuras pode ser reduzida.

    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 notificações em excesso para o usuário apenas para tentar manter seu app no bucket ativo.

  • Se os apps forem divididos em vários pacotes, esses pacotes poderão estar em diferentes buckets 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.

Teste

Para conferir em qual bucket seu app foi colocado, siga um destes procedimentos:

  • Chame getAppStandbyBucket().

  • Execute o seguinte comando em uma janela do terminal:

    adb shell am get-standby-bucket PACKAGE_NAME

O sistema limita o app sempre que ele é colocado em um bucket do App em espera, cujo valor é maior que STANDBY_BUCKET_ACTIVE (10).