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 bloqueios de ativação têm um papel importante. Você está usando demais? Nesta postagem do blog, vamos explicar o que são bloqueios de despertar, 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

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

Esse recurso aumenta a importância da eficiência da bateria junto com os indicadores de estabilidade das métricas principais atuais: falhas e ANRs excessivos percebidos pelo usuário. 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 mostrar um aviso na página "Detalhes do app" para indicar aos usuários que o app pode causar consumo excessivo de bateria.

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

Para dispositivos móveis, a métrica 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 bloqueios de despertar são mantidos por pelo menos duas horas em um período de 24 horas.
• Ele afeta mais de 5% das sessões do app, em média, durante 28 dias.

Os wake locks criados pelas APIs iniciadas pelo usuário audio, location e JobScheduler são isentos do cálculo de wake lock.

Como funcionam 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 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á duas maneiras de adquirir bloqueios de ativação parciais:

• O app adquire e libera manualmente o bloqueio de despertar usando as APIs PowerManager 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 bloqueio de despertar é 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 o download de um arquivo grande iniciado pelo usuário, o uso excessivo ou inadequado pode causar um consumo significativo da bateria. Já vimos casos em que os apps mantêm bloqueios de despertar por horas ou não os liberam corretamente, o que leva a reclamações dos usuários sobre o consumo significativo da bateria, mesmo quando eles não estão interagindo com o app.

Práticas recomendadas para o uso de bloqueio de despertar

Antes de explicar como depurar o uso excessivo de bloqueio de despertar, confira se você está seguindo as práticas recomendadas. 

Considere estas quatro perguntas essenciais.

1. Você já pensou em outras opções de bloqueio de despertar?

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 ativada.
2. O aplicativo está executando um serviço em primeiro plano?
   • Não: não é necessário adquirir um bloqueio de despertar manualmente.
3. Isso prejudica a experiência do usuário?
   • Não: por exemplo, atualizar uma notificação depois que o dispositivo é ativado não exige um bloqueio de ativação.
   • Sim: se for essencial impedir que o dispositivo seja suspenso, como uma comunicação contínua com um dispositivo externo, continue.
4. Já existe uma API mantendo o dispositivo ativo para você?
   • Você pode usar a documentação Identificar bloqueios de despertar criados por outras APIs para identificar cenários em que bloqueios de despertar são criados por outras APIs, como o LocationManager.
   • Se não houver APIs, vá para a pergunta final.
5. Se você respondeu a todas essas perguntas e determinou que não há alternativa, adquira manualmente um wake lock.

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

Ao adquirir bloqueios de despertar manualmente, a nomenclatura adequada é importante para a depuração:

• Não inclua informações de identificação pessoal (PII) no nome, como endereços de e-mail. Se informações desse tipo forem detectadas, o bloqueio de despertar será registrado como _UNKNOWN, dificultando a depuração.
• Não nomeie seu wake lock de forma programática usando nomes de classes ou métodos, já que 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 bloqueio de despertar 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 da bateria. 

Por exemplo, se uma exceção não capturada for gerada durante processamentoWork(), a chamada release() nunca vai 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 bloqueio de despertar 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 periódicas de dados, reduzir a frequência com que o app ativa o dispositivo é fundamental para a otimização da bateria. Alguns exemplos de redução da frequência de ativação:

• WorkManager:aumente o intervalo periódico em PeriodicWorkRequests.
• SensorManager:aproveite o agrupamento em lotes especificando maxReportLatencyMs ao registrar o listener.
• Provedor de localização combinada:
  • 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 que consome menos bateria.
  • Além disso, você pode aproveitar o mecanismo de agrupamento de localizações definindo um intervalo mínimo de atualização com setMinUpdateIntervalMillis.

Confira mais detalhes na documentação de práticas recomendadas de bloqueio de despertar.

Depurar o uso excessivo de wake locks

Mesmo com as melhores intenções, o uso excessivo de bloqueio de despertar pode ocorrer. Se o app for sinalizado no Play Console, confira como depurar:

Identificação inicial com o Play Console

O painel de wake lock parcial excessivo do Android vitals mostra detalhamentos dos nomes de wake lock não isentos associados ao seu app, mostrando sessões e durações afetadas. Lembrete para usar a documentação e identificar se o nome do wake lock é mantido pelo app ou por outra API.

O painel do Android vitals "Wake lock parcial excessivo" rolou para baixo até a seção de detalhamentos para mostrar as tags de wake lock excessivo.

Depuração de bloqueios de ativação excessivos mantidos por workers/jobs

É possível identificar bloqueios de despertar mantidos pelo worker com este nome:

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

A lista completa de variações de nomes de bloqueio de ativação mantido pelo worker está disponível na documentação. Para depurar esses bloqueios de despertar, use o Inspetor de tarefas em segundo plano para depurar localmente ou aproveite 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, em que foi possível identificar um worker "WeatherSyncWorker" que tentou várias vezes e falhou.

Para depurar problemas de WorkManager localmente, use essa ferramenta em um emulador ou dispositivo conectado (nível da API 26 ou mais recente). Ela mostra uma lista de workers e seus status (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 depurar workers com bloqueios de despertar excessivos em campo, use WorkInfo.getStopReason() no WorkManager 2.9.0 ou mais recente ou, para o JobScheduler, JobParameters.getStopReason() disponível no SDK 31 ou mais recente. 

Essa API ajuda a registrar o motivo da interrupção de um worker (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 programação de tarefas para mais detalhes.

Depuração de outros tipos de wake locks excessivos

Em cenários mais complexos que envolvem bloqueios de despertar mantidos manualmente ou APIs que mantêm o bloqueio de despertar, recomendamos usar a coleta de rastreamento do sistema para depurar.

Coleta de rastreamento do sistema

Um rastreamento do sistema  é uma ferramenta de depuração eficiente que captura um registro detalhado da atividade do sistema durante um período, fornecendo insights sobre o estado da CPU, a atividade da linha de execução, a atividade de rede e métricas relacionadas à bateria, como duração do trabalho e uso de bloqueio de despertar.

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

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

Ative a categoria "power:PowerManagement" do Atrace na interface do Perfetto na guia "Apps e serviços do Android". 

Independente do método escolhido, é fundamental garantir que você esteja coletando a categoria "power:PowerManagement" do Atrace para ativar a visualização dos rastreamentos 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. As faixas em que vamos focar neste guia são as que estão em "Estado do dispositivo".

Fixe as faixas em "Estado do dispositivo", como "App principal", "Estado da tela", "Bloqueios de despertar longos" e "Jobs", para identificar visualmente os intervalos de bloqueio de despertar 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 rastreamentos, use a análise de SQL do Perfetto. Uma consulta SQL pode encontrar todos os bloqueios de despertar classificados por duração, ajudando a identificar os principais contribuintes para o uso excessivo.

Confira um exemplo de consulta que soma todas as tags de bloqueio de despertar 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 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 gatilhos de início e fim. Ele oferece mais controle sobre os pontos de acionamento de início e fim da coleta de perfis e impõe a limitação de taxa no nível do sistema para evitar o impacto 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 são semelhantes aos coletados manualmente, mas os processos do sistema e de outros apps são omitidos 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. Usar APIs alternativas, seguir as práticas recomendadas de wake lock e usar ferramentas de depuração eficientes, como o Background Task Inspector, rastreamentos do sistema e o ProfilingManager, é fundamental para garantir o sucesso do app no Google Play.