O sistema prioriza as solicitações de recursos de apps com base no estado do dispositivo, do app e do bucket de espera do app.
O sistema Android pode aplicar limites de recursos de duas maneiras diferentes. Uma maneira de otimizar a utilização de recursos é adiar a execução do trabalho até que o dispositivo tenha saído de um estado de baixo consumo de energia, como o modo Soneca. Por exemplo, jobs regulares e alarmes imprecisos são adiados para serem executados depois que o dispositivo sai do modo de suspensão.
Outra maneira é reduzir a capacidade do app de ativar o dispositivo e fazer o trabalho, com base no bucket de espera atual do app. O sistema pode reduzir a frequência (a frequência com que o app ativa o dispositivo) e a duração total (o tempo que o dispositivo permanece ativo). Por exemplo, se o app estiver no bucket de espera raro, ele poderá executar jobs programados por um período total de 10 minutos em um período contínuo de 24 horas.
O WorkManager usa o JobScheduler para programar tarefas quando o app não está visível e os workers são afetados pelos limites de recursos de jobs.
Para entender melhor as restrições, leia:
- Limites de recursos com base no estado do dispositivo
- Limites de recursos com base no estado do app
- Limites de recursos com base no bucket do App em espera
O estado do dispositivo e do app podem substituir os limites do bucket de standby do app. Por exemplo, se o dispositivo estiver carregando, o sistema permitirá que os apps no bucket de espera raro executem jobs por mais de 10 minutos em um período de 24 horas.
Houve mudanças de comportamento que também afetaram os limites de recursos. Consulte Mudanças de comportamento do Android que afetam os limites de recursos para saber mais.
Limites de recursos com base no estado do dispositivo
O sistema também pode isentar ou aplicar limites de recursos com base no estado do dispositivo. Por exemplo, um dispositivo no estado carregando recebe acesso irrestrito aos recursos, independente do bucket de espera do app.
Estado do dispositivo |
Empregos |
Alarmes |
Acesso à rede |
Firebase Cloud Messaging |
Carregando |
Não há limites de execução, exceto para o bucket de espera restrito. |
Não há limites de execução para todos os buckets de espera e estados de processo, exceto se o usuário restringir manualmente a bateria do app. |
Sem restrições |
Sem restrições |
Tela ativada |
Os limites de execução são aplicados com base no bucket de espera |
Os limites de execução são aplicados com base no processo do app e no bucket em espera. |
O acesso depende do estado do bucket de espera ou do processo do app |
Sem restrições |
A tela está desativada e o modo de suspensão está ativo |
Os limites de execução são aplicados com base no bucket de espera, e a execução é adiada para a janela de manutenção do doze |
Os limites de execução são aplicados com base no bucket de espera. Alarmes regulares: adiados para a janela de manutenção do Doze Alarmes durante inatividade: limitados a 7 por hora |
Restrito durante o modo "Dormir" |
Alta prioridade: sem limites de execução Prioridade normal: adiado para a janela de manutenção |
Limites de recursos com base no estado do app
A aplicação ou não dos limites de recursos do bucket do app em espera
depende da importância do processo do app. Confira
ActivityManager.RunningAppProcessInfo.importance
para entender os diferentes níveis de importância do processo.
O usuário do dispositivo também pode substituir manualmente as otimizações de gerenciamento de energia do app, que substitui os limites de bucket do app em espera.
Estado do aplicativo |
Empregos |
Alarmes |
Rede |
O processo do app está visível ou no estado de primeiro plano |
Sem limites de execução |
Sem limites de frequência |
Sem restrições |
O processo do app está executando um serviço em primeiro plano |
Os limites de execução são aplicados com base no bucket de espera*** |
Os limites de frequência são aplicados com base no bucket de reserva |
Sem restrições |
O usuário restringe manualmente a bateria do app |
A execução é restrita |
A execução é restrita |
O acesso depende do comportamento do bucket de reserva |
O usuário desativa manualmente a restrição de bateria do app |
O limite de execução é generoso*** |
Sem limites de execução |
Ilimitado, a menos que o dispositivo esteja no modo de economia de dados |
*** O comportamento da cota de execução para jobs mudou no Android 16. Antes do Android 16, não havia limite de execução quando o app estava executando um serviço em primeiro plano ou quando o usuário não restringia a bateria do app.
Limites de recursos com base no bucket do App em espera
Observação: os valores nesta tabela não são uma garantia de duração da execução, já que outras condições do dispositivo ou mudanças de bucket podem afetar as restrições de recursos. Os valores também estão sujeitos a mudanças em versões futuras do Android.
Os jobs normais, priorizados, alarmes e o acesso à rede podem ser limitados com base no bucket do App em espera. Entenda como os buckets de suspensão do app afetam seu app usando estas limitações aproximadas de gerenciamento de energia como uma diretriz. Para um desempenho ideal, siga as práticas recomendadas de apps em espera e otimize o uso da bateria para APIs de programação de tarefas.
A partir do Android 13, o bucket em espera do app não determina mais quantos FCMs de alta prioridade podem ser usados.
Bucket do App em espera |
Jobs regulares* |
Jobs priorizados** |
Alarmes |
Rede |
Ativo: |
Até 20 minutos em um período contínuo de 60 minutos*** |
Até 30 minutos em um período de 24 horas*** |
Sem limites de execução |
Sem restrições |
Conjunto de trabalho: |
Até 10 minutos em um período contínuo de 4 horas |
Até 15 minutos em um período contínuo de 24 horas |
Limitado a 10 por hora |
Sem restrições |
Frequente: |
Até 10 minutos em um período de 12 horas |
Até 10 minutos em um período de 24 horas |
Limitado a 2 por hora |
Sem restrições |
Raro: |
Até 10 minutos em um período de 24 horas |
Até 10 minutos em um período de 24 horas |
Limitado a 1 por hora |
Desativado |
Restrito: |
Uma vez por dia por até 10 minutos |
Até 5 minutos em um período de 24 horas |
Um alarme por dia, seja um alarme exato ou um alarme não exato |
Desativado |
* Os jobs regulares descrevem jobs que não usam as flags setUserInitiated(true)
ou setExpedited(true) no JobScheduler ou workers acelerados
no WorkManager.
** Os jobs acelerados têm um limite de execução diferente dos jobs normais. Eles podem ser configurados no WorkManager para continuar sendo executados usando os limites de execução de jobs normais quando os limites acelerados são esgotados.
*** O comportamento da cota de execução para jobs mudou no Android 16. Antes do Android 16, não havia limite de execução quando o app estava no bucket em espera ativo.
Mudanças de comportamento do Android que afetam os limites de recursos
As atualizações do Android a seguir fizeram mudanças nos limites de recursos do app.
Android 16
Mudança no comportamento das otimizações de cota do JobScheduler
O Android ajustou a cota de execução de jobs regulares e acelerados com base nos seguintes fatores:
- Bucket de app em espera em que o app está
- Se o job iniciar a execução enquanto o app estiver em um estado superior
- Se o job estiver sendo executado enquanto um serviço em primeiro plano estiver sendo executado
Android 13
Mudança no comportamento das cotas de alta prioridade do Firebase Cloud Messaging (FCM)
- Os buckets do App em espera não determinam mais quantos FCMs de alta prioridade um app pode usar.
- Agora, o sistema rebaixa as mensagens de alta prioridade se detectar um app enviando mensagens de alta prioridade consistentemente que não resultam em notificações.
- Para conferir as diretrizes atuais sobre mensagens de alta prioridade, consulte a documentação do Firebase sobre como definir e gerenciar a prioridade da mensagem.
Android 9
O recurso de buckets do App em espera é introduzido
O Android 9 introduz um novo recurso de gerenciamento de bateria, os Intervalos de aplicativos em espera Os buckets do App em espera ajudam o sistema a priorizar as solicitações de recursos de apps com base no modo e na frequência com que os apps são usados. Com base nos padrões de uso, 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á.