Otimizar a bateria do app usando a métrica de wake lock do Android vitals

A duração da bateria é um aspecto crucial da experiência do usuário, e os wake locks desempenham um papel importante. Você está usando esses recursos em excesso? Nesta postagem do blog, vamos explicar o que são wake locks, quais são as práticas recomendadas para usá-los e como entender melhor o comportamento do seu app com a métrica do Play Console.

Uso excessivo de wake locks parciais no Android vitals

O Play Console agora monitora o consumo de bateria, com foco no uso excessivo de wake locks parciais, como um indicador principal de desempenho.

Esse recurso aumenta a importância da eficiência da bateria, além dos indicadores de estabilidade das métricas principais: falhas percebidas pelo usuário e ANRs. Definimos um limite de mau comportamento para wake locks em excesso. A partir de 1º de março de 2026, se o título não atender a esse limite de qualidade, ele poderá ser excluído de plataformas de descoberta em destaque, como as recomendações. Em alguns casos, podemos exibir um aviso na página "Detalhes do app" para indicar aos usuários que o app pode causar um consumo excessivo de bateria.

O aviso de wake lock excessivo na Visão geral do Android vitals.

Em dispositivos móveis, a métrica do Android vitals se aplica a wake locks não isentos adquiridos enquanto a tela está desligada e o app está em segundo plano ou executando um serviço em primeiro plano. O Android vitals considera que o uso de wake locks parciais é excessivo se:

• Os wake locks são mantidos por pelo menos duas horas em um período de 24 horas.
• Afeta mais de 5% das sessões do app, em média, em 28 dias.

Os wake locks criados por APIs iniciadas pelo usuário de áudio, local e JobScheduler são isentos do cálculo de wake lock.

Noções básicas sobre wake locks

Um wake lock é um mecanismo que permite que um app mantenha a CPU de um dispositivo em execução mesmo quando o usuário não está interagindo ativamente com ele. 

Um wake lock parcial mantém a CPU em execução mesmo se a tela estiver desligada, impedindo que ela entre em um estado de "suspensão" de baixo consumo de energia. Um wake lock completo mantém a tela e a CPU em execução.

Há dois métodos para adquirir wake locks parciais:

• O app adquire e libera manualmente o wake lock usando as APIs PowerManager para um caso de uso específico. Muitas vezes, isso é feito em conjunto com um serviço em primeiro plano, uma API de ciclo de vida da plataforma destinada a operações perceptíveis pelo usuário.
• Como alternativa, o wake lock é adquirido por outra API e atribuído ao app devido ao uso dela. Saiba mais sobre isso na seção de práticas recomendadas.

Embora os wake locks sejam necessários para tarefas como concluir o download de um arquivo grande iniciado pelo usuário, o uso excessivo ou inadequado deles pode levar a um consumo significativo de bateria. Já vimos casos em que os apps mantêm wake locks por horas ou não os liberam corretamente, o que leva a reclamações dos usuários sobre o consumo significativo de bateria, mesmo quando não estão interagindo com o app.

Práticas recomendadas para o uso de wake locks

Antes de explicarmos como depurar o uso excessivo de wake locks, verifique se você está seguindo as práticas recomendadas para wake locks. 

Considere estas quatro perguntas importantes.

1. Você já considerou outras opções de wake lock?

Antes de considerar a aquisição de um wake lock parcial manual, siga este fluxograma de tomada de decisão:

Fluxograma para decidir quando adquirir manualmente um wake lock

1. A tela precisa ficar ligada?
   • Sim: consulte a documentação Manter a tela ligada
2. O aplicativo está executando um serviço em primeiro plano?
   • Não: não é necessário adquirir manualmente um wake lock.
3. A suspensão do dispositivo prejudica a experiência do usuário?
   • Não: por exemplo, atualizar uma notificação depois que o dispositivo é ativado não requer um wake lock.
   • Sim: se for essencial impedir que o dispositivo seja suspenso, como em uma comunicação contínua com um dispositivo externo, prossiga.
4. Já existe uma API que mantém o dispositivo ativo em seu nome?
   • Consulte a documentação Identificar wake locks criados por outras APIs para identificar cenários em que wake locks são criados por outras APIs, como LocationManager.
   • Se não houver APIs, prossiga para a última pergunta.
5. Se você respondeu a todas essas perguntas e determinou que não há alternativa, prossiga com a aquisição manual de um wake lock.

2. Você está nomeando o wake lock corretamente?

Ao adquirir wake locks manualmente, é importante usar nomes adequados para a depuração:

• Não inclua informações de identificação pessoal (PII, na sigla em inglês) no nome, como endereços de e-mail. Se PII for detectado, o wake lock será registrado como _UNKNOWN, o que dificulta a depuração.
• Não nomeie o wake lock de forma programática usando nomes de classe ou método, porque eles podem ser ofuscados por ferramentas como o Proguard. Em vez disso, use uma string codificada.
• Não adicione contadores ou identificadores exclusivos às tags de wake lock. A mesma tag precisa ser usada sempre que o wake lock for executado para permitir que o sistema agregue o uso por nome, facilitando a detecção de comportamentos anormais.

3. O wake lock adquirido é sempre liberado?

Se você estiver adquirindo um wake lock manualmente, verifique se a liberação dele sempre é executada. Não liberar um wake lock pode causar um consumo significativo de bateria. 

Por exemplo, se uma exceção não capturada for gerada durante processingWork(), a chamada release() pode nunca acontecer. Em vez disso, use um bloco try-finally para garantir que o wake lock seja liberado, mesmo que ocorra uma exceção.

Além disso, é possível adicionar um tempo limite ao wake lock para garantir que ele seja liberado após um período específico, evitando que seja mantido indefinidamente.

fun processingWork() {
    wakeLock.apply {
        try {
            acquire(60 * 10 * 1000) // timeout after 10 minutes
            doTheWork()
        } finally {
            release()
        }
    }
}

4. Você pode reduzir a frequência de ativação?

Para solicitações de dados periódicas, reduzir a frequência com que o app ativa o dispositivo é fundamental para otimizar a bateria. Alguns exemplos de redução da frequência de ativação incluem:

• WorkManager:aumente o intervalo periódico em PeriodicWorkRequests.
• SensorManager:aproveite o processamento em lote especificando maxReportLatencyMs ao registrar o listener.
• Provedor de localização combinada:
  • Reduza a frequência de recuperação de localização usando getLastLocation para o local mais recente em cache.
  • Use setPriority(PRIORITY_PASSIVE) para um método de atualização que consome menos bateria.
  • Além disso, é possível aproveitar o mecanismo de agrupamento de locais definindo um intervalo mínimo de atualização com setMinUpdateIntervalMillis.

Confira mais detalhes na documentação de práticas recomendadas para wake locks.

Como depurar o uso excessivo de wake locks

Mesmo com as melhores intenções, pode ocorrer um uso excessivo de wake locks. Se o app for sinalizado no Play Console, siga estas etapas para depurar:

Identificação inicial com o Play Console

O painel de wake locks parciais excessivos do Android vitals mostra os nomes dos wake locks não isentos associados ao app, além das sessões e durações afetadas. Lembre-se de usar a documentação para identificar se o nome do wake lock é mantido pelo app ou por outra API.

O painel de wake locks parciais em excesso do Android vitals rolou para baixo até a seção de detalhamento para mostrar as tags de wake locks em excesso.

Como depurar wake locks excessivos mantidos por workers/jobs

É possível identificar wake locks mantidos por workers com este nome:

*job*/<package_name>/androidx.work.impl.background.systemjob.SystemJobService

A lista completa de variações de nomes de wake locks mantidos por workers está disponível na documentação. Para depurar esses wake locks, use o Inspetor de Tarefas em Segundo Plano para depurar localmente ou use getStopReason para depurar problemas em campo. 

Inspetor de tarefas em segundo plano do Android Studio

Captura de tela do Inspetor de tarefas em segundo plano, que identificou um worker "WeatherSyncWorker" que falhou e tentou novamente várias vezes.

Para depuração local de problemas do WorkManager, use essa ferramenta em um emulador ou dispositivo conectado (nível da API 26 ou mais recente). Ela mostra uma lista de workers e os status deles (concluído, em execução, na fila), permitindo que você inspecione detalhes e entenda as cadeias de workers. 

Por exemplo, ele pode revelar se um worker está falhando ou tentando novamente com frequência devido a limitações do sistema. 

Consulte a documentação do Inspetor de tarefas em segundo plano para mais detalhes.

getStopReason do WorkManager

Para depurar workers em campo com wake locks excessivos, use WorkInfo.getStopReason() no WorkManager 2.9.0+ ou, para o JobScheduler, JobParameters.getStopReason(), disponível no SDK 31+. 

Essa API ajuda a registrar o motivo pelo qual um worker parou (por exemplo, STOP_REASON_TIMEOUT, STOP_REASON_QUOTA), identificando problemas como tempos limite frequentes devido à duração do ambiente de execução.

backgroundScope.launch {
    WorkManager.getInstance(context)
        .getWorkInfoByIdFlow(workRequest.id)
        .collect { workInfo ->
            logStopReason(workRequest.id, workInfo?.stopReason)
        }
}

Consulte Otimizar o uso da bateria para APIs de programação de tarefas para mais detalhes.

Como depurar outros tipos de wake locks em excesso

Para cenários mais complexos que envolvem wake locks mantidos manualmente ou APIs que mantêm o wake lock, recomendamos usar a coleta de rastreamento do sistema para depuração.

Coleta de rastreamento do sistema

O rastreamento do sistema é uma ferramenta de depuração poderosa que captura um registro detalhado da atividade do sistema durante um período, fornecendo insights sobre o estado da CPU, a atividade de linhas de execução, a atividade da rede e métricas relacionadas à bateria, como duração do job e uso de wake lock.

É possível capturar um rastreamento do sistema usando vários métodos: 

• Usar a ferramenta de linha de comando de rastreamento do sistema
• Usar o CPU Profiler do Android Studio
• Como usar a interface do Perfetto
• Gravar um trace manualmente no dispositivo diretamente nas opções do desenvolvedor. 

Ative a categoria do Atrace "power:PowerManagement" na interface do Perfetto, na guia "Android apps & svcs". 

Seja qual for o método escolhido, é fundamental garantir que você esteja coletando a categoria do Atrace "power:PowerManagement" para permitir a visualização das faixas de estado do dispositivo. 

Inspeção da interface do Perfetto e análise de SQL

Os rastreamentos do sistema podem ser abertos e inspecionados na interface do Perfetto. Ao abrir o trace, você vai ver uma visualização de vários processos em uma linha do tempo. Neste guia, vamos focar nas faixas em "Estado do dispositivo".

Fixe as faixas em "Estado do dispositivo", como "App principal", "Estado da tela", "Wake locks longos" e "Jobs", para identificar visualmente as frações de wake lock de longa duração.

Cada bloco lista o nome do evento, quando ele começou e quando terminou. No Perfetto, isso é chamado de fração.

Para uma análise escalonável de vários traces, use a análise SQL do Perfetto. Uma consulta SQL pode encontrar todos os wake locks classificados por duração, ajudando a identificar os principais fatores que contribuem para o uso excessivo.

Veja um exemplo de consulta que soma todas as tags de wake lock que ocorreram no rastreamento do sistema, ordenadas pela duração total:

SELECT slice.name as name, track.name as track_name,SUM(dur / 100000) as total_dur_ms
FROM slice
JOIN track ON slice.track_id = track.id
WHERE track.name = 'WakeLocks'GROUP BY slice.name, track.name
ORDER BY total_dur_ms DESC

Usar o ProfilingManager para coletar traces em campo

Para problemas difíceis de reproduzir, o ProfilingManager (adicionado no SDK 35) é uma API programática que permite aos desenvolvedores coletar rastreamentos do sistema em campo com acionadores de início e fim. Ele oferece mais controle sobre os pontos de acionamento de início e fim para a coleta de perfis e aplica uma limitação de taxa no nível do sistema para evitar impactos no desempenho do dispositivo. 

Confira a documentação do ProfilingManager para mais etapas sobre como implementar a coleta de rastreamento do sistema em campo, incluindo como capturar um rastreamento, analisar dados de criação de perfil e usar comandos de depuração local de forma programática.

Os rastreamentos do sistema coletados usando o ProfilingManager serão semelhantes aos coletados manualmente, mas os processos do sistema e de outros apps serão removidos do rastreamento.

Conclusão

A métrica de wake lock parcial em excesso no Android vitals é apenas uma pequena parte do nosso compromisso contínuo de ajudar os desenvolvedores a reduzir o consumo de bateria e melhorar a qualidade dos apps. 

Ao entender e implementar corretamente os wake locks, você pode otimizar significativamente o desempenho da bateria do app. Aproveitar APIs alternativas, seguir as práticas recomendadas de wake lock e usar ferramentas de depuração avançadas, como o Inspetor de tarefas em segundo plano, os rastreamentos do sistema e o ProfilingManager, são essenciais para garantir o sucesso do seu app no Google Play.