App Standby — o que é, níveis de espera e princípio de funcionamento

O que é App Standby

App Standby é um componente do sistema de gerenciamento de energia do Android, introduzido no Android 6.0 (API 23) e significativamente reformulado no Android 9 (API 28). Sua função é identificar quais aplicativos o usuário usa raramente e restringir sua atividade em segundo plano: requisições de rede, sincronização, JobScheduler e AlarmManager. Ao contrário do Doze, o App Standby não depende do estado da tela ou do movimento do dispositivo.

O sistema classifica os aplicativos em quatro buckets (níveis): Active, Working Set, Frequent e Rare. Cada nível determina o quão fortemente a atividade em segundo plano é restringida. As transições entre níveis ocorrem automaticamente com base nos padrões de uso do aplicativo: com que frequência o usuário o abre, recebe notificações, interage com widgets.

O App Standby trabalha em conjunto com o Doze Mode mas não o substitui. Enquanto o Doze limita a atividade em segundo plano de todos os aplicativos quando o dispositivo está ocioso, o App Standby restringe aplicativos específicos independentemente do estado do dispositivo. Um aplicativo no nível Rare enfrentará restrições mesmo quando o telefone estiver sendo usado ativamente, se o usuário não o abriu por vários dias.

Buckets no Android 9+

A partir do Android 9 (API 28), o Google introduziu os App Standby Buckets — uma classificação formal com valores numéricos. O sistema usa aprendizado de máquina para prever a próxima vez que um aplicativo será iniciado. Se o modelo previr que o aplicativo será aberto nas próximas horas, ele recebe um bucket Active. Se a previsão indicar uso raro — é atribuído Rare.

Como funciona o App Standby

App Standby analisa vários fatores para determinar o bucket: tempo desde a última vez que o usuário abriu o aplicativo, frequência de interação (número de inicializações por dia/semana), recebimento de notificações FCM, presença de widgets ativos na tela inicial e subscrição ao AlarmManager. Quanto mais tempo um aplicativo fica sem uso, menor é seu bucket e mais rigorosas são as restrições.

O serviço do sistema UsageStatsManager coleta estatísticas de uso de aplicativos e as passa para o StandbyController — um componente do framework que calcula o bucket para cada aplicativo. O StandbyController também leva em conta eventos do sistema: após uma atualização do aplicativo, seu bucket é redefinido para Active por alguns dias para que o usuário possa avaliar as novas funcionalidades.

Uma característica importante: o App Standby não encerra o processo do aplicativo, mas limita suas capacidades em segundo plano. O aplicativo continua funcionando se o usuário estiver interagindo com ele (bucket Active). Assim que o usuário minimiza o aplicativo e não retorna a ele, o sistema começa a contar o tempo de inatividade e pode reduzir o bucket para Working Set ou Frequent.

Impacto do FCM no bucket

Receber uma mensagem FCM de alta prioridade pode aumentar temporariamente o bucket do aplicativo para Active. Isso dá ao aplicativo a oportunidade de realizar uma tarefa (processar a mensagem, sincronizar dados) sem restrições. No entanto, após a conclusão do processamento, o bucket retorna ao seu valor original. O Google recomenda usar este mecanismo para entregar notificações importantes, não para manter o aplicativo ativo.

Níveis do App Standby

App Standby usa quatro níveis (buckets) para classificar aplicativos. Cada nível determina o tempo de atraso para tarefas em segundo plano: quanto menor o nível, maior o atraso. O sistema move automaticamente o aplicativo entre os níveis com base nas estatísticas de uso coletadas nos últimos 7–14 dias.

Active — Aplicativo ativo

Active — um aplicativo com o qual o usuário interagiu recentemente (iniciou, recebeu uma notificação ou usou um widget). Neste bucket não há restrições: o JobScheduler executa imediatamente, a rede está disponível, o AlarmManager dispara com precisão. O aplicativo permanece em Active até que o usuário pare de interagir com ele por várias horas.

Working Set e Frequent

Working Set — o aplicativo é usado regularmente (várias vezes por semana). Atraso de tarefas em segundo plano de até 2 horas. Frequent — o aplicativo é usado várias vezes por mês. Atraso de até 4 horas. Em ambos os níveis, a rede só está disponível em janelas de manutenção, e o AlarmManager pode ser adiado. O JobScheduler executa tarefas na janela mais próxima.

Rare — Raramente usado

Rare — o nível mais rigoroso, atribuído a aplicativos que o usuário não abriu por mais de 30 dias. O atraso de tarefas em segundo plano chega a 24 horas. A rede fica completamente bloqueada fora das janelas de manutenção, o AlarmManager só dispara com flags setAndAllowWhileIdle() com limite de 1 vez a cada 9 minutos. As notificações FCM de alta prioridade ainda são entregues mas não podem aumentar o bucket.

Restrições do App Standby

App Standby impõe restrições a várias categorias de operações em segundo plano. Ao contrário do Doze, as restrições do App Standby se aplicam independentemente do estado da tela e do carregamento. O desenvolvedor deve projetar o aplicativo considerando essas restrições, especialmente se o público-alvo usa o aplicativo irregularmente.

JobScheduler e WorkManager

JobScheduler — a principal API afetada pelo App Standby. Dependendo do bucket, o atraso na execução de tarefas varia de 2 a 24 horas. O WorkManager, que usa JobScheduler internamente (na API 23+), também está sujeito a esses atrasos. Para tarefas críticas quanto ao tempo, use o Expedited Work, que inicia um Foreground Service internamente e não é afetado pelo bucket.

Restrições de rede

Aplicativos nos buckets Working Set, Frequent e Rare não podem fazer requisições de rede arbitrárias a qualquer momento. O sistema só permite acesso à rede durante janelas de manutenção, que são sincronizadas com o Doze. Para enviar dados críticos, use FCM de alta prioridade com sincronização subsequente na janela de manutenção.

AlarmManager

AlarmManager no App Standby segue as mesmas regras do Doze: alarmes exatos (setExact()) são adiados, e setAndAllowWhileIdle() é limitado a 1 disparo a cada 9 minutos. Para o bucket Rare, o atraso pode chegar a 24 horas, tornando o AlarmManager inadequado para agendamento preciso de tarefas em aplicativos raramente usados.

• JobScheduler — tarefas são adiadas por 2–24 horas dependendo do bucket
• Rede — acesso apenas em janelas de manutenção para Working Set e inferiores
• AlarmManager — alarmes exatos são adiados; setAndAllowWhileIdle — 1/9 min
• SyncManager — sincronização de contas é adiada até a janela de manutenção
• Widget updates — a frequência de atualização de widgets pode ser reduzida

Como obter uma exceção

Uma exceção do App Standby pode ser obtida de duas formas: através das configurações de bateria do usuário (Whitelist manual) ou através da Intent do sistema ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS. No entanto, o Google regula rigorosamente o acesso a exceções — aplicativos sem um motivo válido correm o risco de serem rejeitados no Google Play.

O usuário pode desativar manualmente as restrições para um aplicativo específico através de Configurações → Aplicativos → [Aplicativo] → Bateria → Otimização → Não otimizar. Isso remove completamente as restrições do App Standby e Doze para o aplicativo selecionado. O desenvolvedor pode mostrar instruções ou um diálogo do sistema ao usuário, mas não pode forçar a adição de um aplicativo às exceções.

Foreground Service com uma notificação obtém automaticamente uma exceção temporária do App Standby. Enquanto o serviço estiver em execução e exibindo uma notificação, o aplicativo é movido para o bucket Active independentemente do seu nível real. Após a parada do serviço, o bucket retorna ao seu valor original. Esta é a forma mais confiável de garantir trabalho em segundo plano sem solicitar exceções do sistema.

Quando solicitar uma exceção

Solicitar uma Whitelist só faz sentido para aplicativos com funcionalidade crítica em segundo plano: navegação em tempo real, monitoramento de saúde, chamadas VoIP, proteção do dispositivo. Para a maioria dos aplicativos, é suficiente usar Foreground Service ou WorkManager. O Google Play pode rejeitar a publicação se o aplicativo solicitar uma exceção sem necessidade óbvia.

// Solicitar exceção do App Standby
val intent = Intent(Settings.ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS).apply {
    data = Uri.parse("package:\${applicationContext.packageName}")
}

// Verificar status atual
val powerManager = getSystemService(Context.POWER_SERVICE) as PowerManager
val isIgnoring = powerManager.isIgnoringBatteryOptimizations(packageName)

Testando o App Standby

Testar o App Standby via ADB permite atribuir forçadamente qualquer bucket a um aplicativo e verificar seu comportamento. Isso é criticamente importante para aplicativos que dependem de sincronização em segundo plano, notificações ou atualizações periódicas. O teste deve ser realizado em um dispositivo físico ou emulador com Android 9+.

Para definir forçadamente um bucket, use o comando adb shell am set-standby-bucket [package] [bucket], onde bucket pode ser: active, working_set, frequent ou rare. Para visualizar o bucket atual — adb shell am get-standby-bucket [package]. O sistema também permite simular inatividade prolongada do aplicativo através do comando adb shell dumpsys usagestats.

# Definir bucket Rare para o aplicativo
$ adb shell am set-standby-bucket com.example.app rare

# Ver bucket atual
$ adb shell am get-standby-bucket com.example.app

# Redefinir todos os buckets para Active
$ adb shell dumpsys usagestats clear

# Ver todos os buckets do sistema
$ adb shell dumpsys usagestats

O que verificar

Após definir o bucket como Rare, verifique: se a tarefa do WorkManager executa em 24 horas, se o AlarmManager dispara, se as notificações FCM são entregues e se o Foreground Service funciona sem restrições. O WorkManager com política de Expedited Work deve executar imediatamente mesmo no bucket Rare, pois usa Foreground Service. As tarefas normais do WorkManager serão adiadas conforme o bucket.

Melhores práticas

Desenvolver um aplicativo resiliente ao App Standby requer uma abordagem consciente para tarefas em segundo plano. O princípio principal: não presumir que o aplicativo está sempre no bucket Active. Projete o trabalho em segundo plano para que ele seja executado corretamente com os atrasos característicos dos buckets Frequent e Rare.

Use WorkManager com Expedited Work

Expedited Work (WorkManager 2.7+) inicia um Foreground Service internamente, dando à tarefa execução imediata independentemente do bucket. Esta é a escolha ideal para tarefas que não podem ser adiadas: envio de mensagem, sincronização após pagamento, processamento de chamada recebida. As tarefas normais do WorkManager são executadas em janelas de manutenção conforme o bucket.

FCM para reativação

Use mensagens FCM de alta prioridade para despertar um aplicativo do App Standby. Quando o aplicativo recebe tal mensagem, seu bucket é temporariamente elevado para Active, permitindo que ele realize tarefas necessárias (sincronizar, atualizar dados). Após a conclusão do processamento, o bucket retorna ao seu nível original.

Evite retenção constante na memória

Não tente contornar o App Standby com serviços em segundo plano persistentes, WakeLock ou mensagens FCM periódicas. O Google combate ativamente tais práticas — o aplicativo pode ser marcado como consumidor de energia e restringido ainda mais severamente. Use WorkManager para tarefas periódicas e Foreground Service apenas quando a tarefa for realmente visível para o usuário.

• WorkManager — API preferida; Expedited Work executa tarefas sem atraso
• FCM de alta prioridade — aumenta temporariamente o bucket para Active para processamento de mensagem
• Não contorne o App Standby — isso leva ao bloqueio do aplicativo pelo sistema
• Foreground Service — move temporariamente o aplicativo para Active enquanto está em execução
• Teste o aplicativo nos buckets Rare e Frequent via ADB antes de cada lançamento