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 os 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 elevado da 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 de métricas principais atuais: falhas e erros ANR excessivos percebidos pelo usuário.Definimos um limite de mau comportamento para wake locks excessivos. A partir de 1º de março de 2026, se o título não atender a esse limite de qualidade, poderemos excluí-lo de superfícies de descoberta importantes, como recomendações. Em alguns casos, podemos mostrar um aviso na página de detalhes do app para indicar aos usuários que o app pode causar consumo elevado da bateria.

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

Para 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 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.
• Isso afeta mais de 5% das sessões do app, em média, durante 28 dias.

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

Entender os 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 que a tela esteja desligada, impedindo que a CPU entre em um estado de "suspensão" de baixa 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 PowerManager APIs para um caso de uso específico. Geralmente, isso é adquirido 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 da API. Saiba mais sobre isso na seção de práticas recomendadas.

Embora os wake locks sejam necessários para tarefas como concluir um download de um arquivo grande iniciado pelo usuário, o uso excessivo ou inadequado deles pode levar a um consumo elevado da 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 elevado da bateria, mesmo quando eles não estão interagindo com o app.

Práticas recomendadas para o uso de wake locks

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

Considere estas quatro perguntas importantes.

1. Você considerou opções alternativas 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 um wake lock manualmente.
3. É prejudicial à experiência do usuário se o dispositivo for suspenso?
   • Não: por exemplo, atualizar uma notificação depois que o dispositivo é ativado não requer um wake lock.
   • Sim: se for fundamental impedir que o dispositivo seja suspenso, como a comunicação contínua com um dispositivo externo, continue.
4. Já existe uma API mantendo o dispositivo ativado em seu nome?
   • Você pode consultar 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, continue para a pergunta final.
5. Se você respondeu a todas essas perguntas e determinou que não há alternativa, continue com a aquisição manual de um wake lock.

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

Ao adquirir wake locks manualmente, a nomenclatura adequada é importante 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 forem detectadas PIIs, o wake lock será registrado como _UNKNOWN, dificultando 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 do wake lock sempre é executada. Não liberar um wake lock pode causar um consumo elevado da bateria. 

Por exemplo, se uma exceção não detectada for gerada durante processingWork(), a chamada release() poderá nunca acontecer. Em vez disso, você pode usar 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, impedindo que ele seja mantido indefinidamente.

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

4. É possível 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 a otimização da bateria. Confira alguns exemplos de como reduzir a frequência de ativação:

• WorkManager: aumente o intervalo periódico em PeriodicWorkRequests.
• SensorManager: aproveite o agrupamento em lote especificando maxReportLatencyMs ao registrar o listener.
• Fused Location Provider:
  • Reduza a frequência de recuperação de localização usando getLastLocation para a localização em cache mais recente.
  • Use setPriority(PRIORITY_PASSIVE) para um método de atualização menos intensivo em termos de bateria.
  • Além disso, você pode aproveitar o mecanismo de agrupamento de localização definindo um intervalo mínimo de atualização com setMinUpdateIntervalMillis.

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

Depurar o uso excessivo de wake locks

Mesmo com as melhores intenções, o uso excessivo de wake locks pode ocorrer. Se o app for sinalizado no Play Console, confira como depurá-lo:

Identificação inicial com o Play Console

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

O painel de wake locks parciais excessivos do Android vitals rolou até a seção de detalhamentos para mostrar tags de wake locks excessivos.

Depurar wake locks excessivos mantidos por workers/jobs

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

*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 aproveite getStopReason para depurar problemas no campo. 

Inspetor de tarefas em segundo plano do Android Studio

Captura de tela do Inspetor de tarefas em segundo plano, em que foi possível identificar um worker "WeatherSyncWorker" que tentou e falhou com frequência.

Para depuração local de problemas do WorkManager, use essa ferramenta em um emulador ou dispositivo conectado (nível 26 da API ou mais recente). Ele mostra uma lista de workers e os status deles (concluído, em execução, enfileirado), 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.

WorkManager getStopReason

Para depuração no campo de workers com wake locks excessivos, use WorkInfo.getStopReason() no WorkManager 2.9.0 ou mais recente ou, para JobScheduler, JobParameters.getStopReason() disponível no SDK 31 ou mais recente. 

Essa API ajuda a registrar o motivo pelo qual um worker foi interrompido (por exemplo, STOP_REASON_TIMEOUT, STOP_REASON_QUOTA), identificando problemas como tempos limite frequentes devido ao esgotamento da 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 agendamento de tarefas para mais detalhes.

Depurar outros tipos de wake locks excessivos

Para cenários mais complexos que envolvem wake locks mantidos manualmente ou APIs que mantêm o wake lock, recomendamos o uso da coleta de rastreamento do sistema para depurar.

Coleta de rastreamento do sistema

Um rastreamento do sistema é uma ferramenta de depuração avançada 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 de rede e métricas relacionadas à bateria, como a duração do job e o uso de wake locks.

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

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

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

Independentemente do método escolhido, é fundamental garantir que você esteja coletando a "power:PowerManagement" Atrace category para permitir a visualização de rastros 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 rastreamento, você verá uma visualização de vários processos em uma linha do tempo. Os rastros em que vamos nos concentrar neste guia são aqueles em "Estado do dispositivo".

Fixe os rastros em "Estado do dispositivo", como "App principal", "Estado da tela", "Wake locks longos" e "Jobs", para identificar visualmente fatias de wake locks de longa duração.

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

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

Confira 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 coleta de rastreamento no campo

Para problemas difíceis de reproduzir, o ProfilingManager (adicionado no SDK 35) é uma API programática que permite que os desenvolvedores coletem rastreamentos do sistema no 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 a limitação de taxa no nível do sistema para evitar o impacto no desempenho do dispositivo. 

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

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

Conclusão

A métrica de wake lock parcial excessivo no Android vitals é apenas uma pequena parte do nosso compromisso contínuo de oferecer suporte aos desenvolvedores na redução do consumo elevado da bateria e na melhoria da qualidade do app. 

Ao entender e implementar corretamente os wake locks, você pode otimizar significativamente a performance 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, rastreamentos do sistema e ProfilingManager, são fundamentais para garantir o sucesso do app no Google Play.