Buckets do App em espera (original) (raw)

O Android 9 (nível 28 da API) e versões mais recentes têm suporte aos buckets do App em espera. Esses contêineres 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. 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 aplicativo está.

Buckets de prioridade

O sistema atribui dinamicamente cada app a um bucket de prioridade, reatribuindo 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 adequados.

Se o app do sistema não estiver presente em um dispositivo, o padrão será classificar os aplicativos com base na data em que eles foram usados. Os apps mais ativos são atribuídos a buckets com maior prioridade, disponibilizando mais recursos do sistema. Especificamente, o bucket determina com que frequência os jobs do app são executados e o app pode acionar alarmes. Essas restrições se aplicam somente enquanto o dispositivo está usando a energia da bateria. Enquanto o dispositivo está carregando, o sistema não impõe essas restrições.

Os buckets prioritários são os seguintes:

• Ativo: o app está sendo ou foi usado recentemente.
• Conjunto de trabalho: o app está em uso regular.
• Frequente: o app costuma ser usado, mas não diariamente.
• Raro: o app não é usado com frequência.
• Restrito: o app consome muitos recursos do sistema ou pode apresentar comportamento indesejado.

Além desses buckets prioritários, há um bucket nunca especial para apps instalados, mas que nunca são executados. O sistema impõe restrições severas a esses apps.

As descrições a seguir são para o caso não preditivo. Por outro lado, quando a previsão usa machine learning para prever um comportamento, os buckets são escolhidos antes das próximas ações do usuário, não com base no uso recente. Por exemplo, um app usado recentemente pode acabar no bucket raro porque o machine learning prevê que o aplicativo não será usado por várias horas.

Ativo

Um app fica no bucket ativo enquanto está sendo usado, se tiver sido usado muito recentemente ou quando:

• Inicia uma atividade.
• Executa um serviço em primeiro plano de longa duração.
• É tocado pelo usuário usando uma notificação.

Se um app estiver no bucket ativo, o sistema vai colocar restrições mínimas para jobs ou alarmes do app:

• A partir do Android 16 (nível 36 da API), os jobs em segundo plano têm uma cota de tempo de execução generosa se forem iniciados por um app no bucket ativo. Isso inclui jobs programados diretamente com JobScheduler, bem como jobs criados por outras bibliotecas, como o WorkManager ou o DownloadManager.

A interação do usuário atribui apps como ativos

No Android 9 (nível 28 da API) e versões mais recentes, quando o usuário interage com um app de determinadas maneiras, o sistema coloca o app temporariamente no bucket ativo. 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 a seguir 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 tocando em um botão de mídia.
• O usuário se conectou ao app ao interagir com oAndroid Automotive OS, em que o aplicativo usa um serviço em primeiro plano ouCONNECTION_TYPE_PROJECTION.

Conjunto de trabalho

Um app vai para o bucket conjunto de trabalho quando é executado com frequência, mas não está ativo. 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 Limites de recursos 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 nesse bucket, o sistema vai impor restrições mais rígidas à capacidade de executar jobs e acionar alarmes. Para saber detalhes, consulte Limites de recursos do gerenciamento de energia.

Rara

Um app vai para o bucket raro quando não é usado com frequência. Por exemplo, um app de hotel que o usuário executa somente quando 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 e acionar alarmes. O sistema também limita a capacidade do app de se conectar à Internet. Para saber detalhes, consulte Limites de recursos do 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 será colocado no bucket restrito.

No Android 13 (nível 33 da API) e versões mais recentes, exceto em casos em que há umaisençã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. O Android 13 reduz o número de dias para 8.
• O app invoca um número excessivo de transmissões ou vinculaçõesem um período de 24 horas.

Se o sistema colocar o app no bucket restrito, as restrições abaixo serão 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 aplicativos.
  • Os jobs restritos não são executados sozinhos. É preciso que haja pelo menos um outro job em execução ou pendente ao mesmo tempo, o que pode incluir qualquer outro job.
• O app pode executar menos jobs priorizados do que quando o sistema coloca o app em um bucket menos restritivo.
• Seu app pode invocar um alarme por dia. Esse pode ser um alarme exato ou impreciso.

Isenções do bucket restrito

Os tipos de apps abaixo estão isentos de serem colocados no bucket restrito e ignorar o acionador de inatividade, mesmo no Android 12 e versões mais recentes:

• Apps complementares de dispositivos
• Apps executados em um dispositivo no modo de demonstração
• Apps do proprietário do dispositivo
• Apps do proprietário do perfil
• Apps persistentes
• Apps de VPN
• Apps que têm o papel ROLE_DIALER
• Apps que o usuário designou explicitamente como "sem restrições" nas configurações do sistema
• Apps com widgets ativos
• Apps que recebem pelo menos uma destas permissões:
  • USE_EXACT_ALARM
  • ACCESS_BACKGROUND_LOCATION

Avaliar o bucket de prioridade

Para verificar a qual bucket seu app está atribuído, 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).

Práticas recomendadas

Se o app estiver seguindo as práticas recomendadas para Soneca e App em espera, os recursos posteriores de gerenciamento de energia não serão difíceis. No entanto, o comportamento de alguns apps que funcionavam bem agora pode causar problemas.

• Não tente manipular o sistema para colocar seu app em um determinado bucket. O método de colocação de prioridade do sistema pode 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. Reformule seu app para ter essa atividade.
• Se os usuários não puderem interagir com as notificações do app, eles não poderão acionar a promoção dele para o bucket ativo. Nesse caso, considere redefinir algumas notificações que permitam que os usuários interajam. Para conferir algumas diretrizes, consulte os padrões de design de notificações (link em inglês) do Material Design.
• 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 poderá interagir com ele 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. Portanto, essa situação nunca vai 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 poderá ser reduzida.
• Se os apps forem divididos em vários pacotes, eles 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.