Sabendo que o consumo elevado da bateria é o mais lembrado para os usuários do Android, o Google tem tomado medidas significativas para ajudar os desenvolvedores a criar apps mais eficientes em termos de energia. Em 1º de março de 2026, a Google Play Store começou a lançar os tratamentos de qualidade técnica de wake lock para melhorar o consumo elevado da bateria. Esse tratamento será lançado gradualmente para os apps afetados nas próximas semanas. Os apps que excedem consistentemente o limite de "Wake lock parcial excessivo" no Android vitals podem ter impactos tangíveis na presença na loja, incluindo avisos na página "Detalhes do app" e exclusão de plataformas de descoberta, como recomendações.

Os usuários podem ver um aviso na página "Detalhes do app" se o app exceder o limite de mau comportamento. 

Essa iniciativa elevou a eficiência da bateria a uma métrica vital principal, junto com métricas de estabilidade, como falhas e ANRs. O "limite de mau comportamento" é definido como manter um wake lock parcial não isento por pelo menos duas horas em média enquanto a tela está desligada em mais de 5% das sessões de usuário nos últimos 28 dias. Um wake lock é dispensado se for um wake lock mantido pelo sistema que oferece benefícios claros ao usuário que não podem ser mais otimizados, como reprodução de áudio, acesso à localização ou transferência de dados iniciada pelo usuário. Confira a definição completa de wake locks excessivos na documentação do Android vitals.

Como parte da nossa iniciativa contínua para melhorar a duração da bateria em todo o ecossistema Android, analisamos milhares de apps e como eles usam bloqueios de despertar parciais. Embora os bloqueios de despertar sejam necessários às vezes, muitas vezes vemos apps mantendo-os de maneira ineficiente ou desnecessária, quando existem soluções mais eficientes. Nesta postagem do blog, vamos abordar os cenários mais comuns em que ocorrem bloqueios de despertar excessivos e nossas recomendações para otimizar esses bloqueios.  Já vimos um sucesso mensurável de parceiros como a WHOOP, que aproveitou essas recomendações para otimizar o comportamento em segundo plano.

Usar um serviço em primeiro plano x bloqueios de despertar parciais

Muitas vezes, os desenvolvedores têm dificuldade em entender a diferença entre dois conceitos ao fazer a execução em segundo plano: serviço em primeiro plano e bloqueios de despertar parciais.

Um serviço em primeiro plano é uma API de ciclo de vida que sinaliza ao sistema que um app está realizando um trabalho perceptível para o usuário e não deve ser encerrado para recuperar memória. No entanto, ele não impede automaticamente que a CPU entre em modo de suspensão quando a tela é desligada. Em contraste, um wake lock parcial é um mecanismo projetado especificamente para manter a CPU em execução mesmo com a tela desligada.

Embora um serviço em primeiro plano seja muitas vezes necessário para continuar uma ação do usuário, uma aquisição manual de um wake lock parcial só é necessária em conjunto com um serviço em primeiro plano durante a atividade da CPU. Além disso, não é necessário usar um wake lock se você já estiver utilizando uma API que mantém o dispositivo ativo. 

Consulte o fluxograma em Escolher a API certa para manter o dispositivo ativo e entenda qual ferramenta usar para evitar a aquisição de um wake lock em cenários desnecessários.

Bibliotecas de terceiros que adquirem wake locks

É comum que um app descubra que foi sinalizado por bloqueios de ativação excessivos mantidos por um SDK de terceiros ou uma API do sistema agindo em nome dele. Para identificar e resolver esses bloqueios de ativação, recomendamos as seguintes etapas:

• Verifique o Android vitals:encontre o nome exato do wake lock ofensivo no painel de wake locks parciais excessivos. Compare este nome com a orientação Identificar bloqueios de despertar criados por outras APIs para saber se ele foi criado por uma API de sistema conhecida ou uma biblioteca Jetpack. Se for, talvez seja necessário otimizar o uso da API e consultar as orientações recomendadas.
• Capture um rastreamento do sistema:se o wake lock não puder ser identificado facilmente, reproduza o problema localmente usando um rastreamento do sistema e inspecione-o com a interface do Perfetto. Saiba mais sobre como fazer isso na seção Depuração de outros tipos de bloqueios de ativação excessivos desta postagem do blog.
• Avalie alternativas:se uma biblioteca de terceiros ineficiente for responsável e não puder ser configurada para respeitar a duração da bateria, comunique o problema aos proprietários do SDK, encontre um SDK alternativo ou crie a funcionalidade internamente.

Cenários comuns de wake lock

Confira abaixo um detalhamento de alguns casos de uso específicos que revisamos, além do caminho recomendado para otimizar a implementação do wake lock.

Upload ou download iniciado pelo usuário

Exemplos de casos de uso: 

• Apps de streaming de vídeo em que o usuário aciona o download de um arquivo grande para acesso off-line.
• Apps de backup de mídia em que o usuário aciona o upload das fotos recentes por uma solicitação de notificação.

Como reduzir wake locks: 

• Não adquira um wake lock manual. Em vez disso, use a API de transferência de dados iniciada pelo usuário (UIDT). Esse é o caminho designado para tarefas de transferência de dados de longa duração iniciadas pelo usuário, e ele é isento de cálculos excessivos de wake lock.

Sincronizações em segundo plano únicas ou periódicas

Exemplos de casos de uso: 

• Um app faz sincronizações periódicas em segundo plano para buscar dados para acesso off-line. 
• Apps de pedômetro que buscam a contagem de passos periodicamente.

Como reduzir wake locks: 

• Não adquira um wake lock manual. Use o WorkManager configurado para trabalho único ou periódico. O WorkManager respeita a integridade do sistema agrupando tarefas e tem um intervalo periódico mínimo (15 minutos), que geralmente é suficiente para atualizações em segundo plano. 
• Se você identificar wake locks criados por WorkManager ou JobScheduler com alto uso de wake lock, isso pode ocorrer porque você configurou incorretamente o worker para não ser concluído em determinados cenários. Considere analisar os motivos de interrupção do worker, principalmente se você estiver observando muitas ocorrências de STOP_REASON_TIMEOUT. 

  workManager.getWorkInfoByIdFlow(syncWorker.id)
  .collect { workInfo ->
      if (workInfo != null) {
        val stopReason = workInfo.stopReason
        logStopReason(syncWorker.id, stopReason)
      }
  }

• Além de registrar os motivos da interrupção do worker, consulte nossa documentação sobre depuração de workers. Além disso, considere coletar e analisar rastreamentos do sistema  para entender quando os bloqueios de despertar são adquiridos e liberados.
• Por fim, confira nosso estudo de caso com a WHOOP, em que a empresa descobriu um problema na configuração dos workers e reduziu significativamente o impacto do wake lock.

Comunicação Bluetooth

Exemplos de casos de uso: 

• O app do dispositivo complementar pede que o usuário pareie o dispositivo externo Bluetooth.
• O app do dispositivo complementar fica aguardando eventos de hardware em um dispositivo externo e mudanças visíveis para o usuário na notificação.
• O usuário do app do dispositivo complementar inicia uma transferência de arquivos entre o dispositivo móvel e o Bluetooth.
• O app do dispositivo complementar faz atualizações ocasionais de firmware em um dispositivo externo via Bluetooth.

Como reduzir wake locks: 

• Use o pareamento de dispositivos complementares para parear dispositivos Bluetooth e evitar adquirir um wake lock manual durante o pareamento. 
• Consulte as orientações sobre  comunicação em segundo plano para entender como fazer a comunicação Bluetooth em segundo plano. 
• Usar WorkManager geralmente é suficiente se não houver impacto para o usuário em uma comunicação atrasada. Se um wake lock manual for considerado necessário, mantenha o wake lock apenas durante a atividade do Bluetooth ou o processamento dos dados de atividade.

Rastreamento de local

Exemplos de casos de uso: 

• Apps de fitness que armazenam dados de localização em cache para upload posterior, como o traçado de rotas de corrida
• Apps de entrega de comida que extraem dados de localização com alta frequência para atualizar o progresso da entrega em uma notificação ou interface de widget.

Como reduzir wake locks: 

• Consulte nossas orientações para otimizar o uso de locais. Considere implementar tempos limite, usar o agrupamento em lote de solicitações de localização ou utilizar atualizações de localização passivas para garantir a eficiência da bateria.
• Ao solicitar atualizações de localização usando as APIs FusedLocationProvider ou LocationManager, o sistema aciona automaticamente a ativação do dispositivo durante o callback do evento de localização. Esse wake lock breve e gerenciado pelo sistema é isento dos cálculos de wake lock parcial em excesso.
• Evite adquirir um wake lock contínuo separado para armazenar dados de localização em cache, já que isso é redundante. Em vez disso, persista eventos de localização na memória ou no armazenamento local e use o WorkManager para processá-los em intervalos periódicos.

  override fun onCreate(savedInstanceState: Bundle?) {
    locationCallback = object : LocationCallback() {
        override fun onLocationResult(locationResult: LocationResult?) {
            locationResult ?: return
            // System wakes up CPU for short duration
            for (location in locationResult.locations){
                // Store data in memory to process at another time
            }
        }
    }
}

Monitoramento de sensores de alta frequência

Exemplos de casos de uso: 

• Apps de pedômetro que coletam passivamente etapas ou distância percorrida. 
• Apps de segurança que monitoram os sensores do dispositivo em tempo real para detectar mudanças rápidas e oferecer recursos como detecção de acidentes ou quedas.

Como reduzir wake locks: 

• Se você estiver usando SensorManager, reduza o uso para intervalos periódicos e somente quando o usuário tiver concedido acesso explicitamente por uma interação da interface. O monitoramento de sensores de alta frequência pode consumir muita bateria devido ao número de ativações e processamentos da CPU.
• Se você estiver rastreando contagens de passos ou distância percorrida, em vez de usar o SensorManager, aproveite a API Recording ou use o Conexão Saúde para acessar contagens de passos históricas e agregadas do dispositivo e capturar dados de maneira eficiente em termos de bateria.
• Se você estiver registrando um sensor com SensorManager, especifique um maxReportLatencyUs de 30 segundos ou mais para aproveitar o agrupamento de sensores e minimizar a frequência de interrupções da CPU. Quando o dispositivo é ativado por outro gatilho, como uma interação do usuário, recuperação de local ou um job programado, o sistema envia imediatamente os dados do sensor armazenados em cache.

  val accelerometer = sensorManager.getDefaultSensor(Sensor.TYPE_ACCELEROMETER)

sensorManager.registerListener(this,
                 accelerometer,
                 samplingPeriodUs, // How often to sample data
                 maxReportLatencyUs // Key for sensor batching 
              )

• Se o app exigir dados de local e dados do sensor, sincronize a recuperação e o processamento de eventos. Ao aproveitar as leituras do sensor no breve wake lock que o sistema mantém para atualizações de localização, você evita a necessidade de um wake lock para manter a CPU ativa. Use um worker ou um wake lock de curta duração para processar o upload e o processamento desses dados combinados.

Mensagens remotas

Exemplos de casos de uso: 

• Apps complementares de monitoramento de vídeo ou som que precisam monitorar eventos que ocorrem em um dispositivo externo conectado usando uma rede local.
• Apps de mensagens que mantêm uma conexão de soquete de rede com a variante para computador.

Como reduzir wake locks: 

• Se os eventos de rede puderem ser processados no lado do servidor, use o FCM para receber informações no cliente. Você pode agendar um trabalhador acelerado se for necessário processar mais dados do FCM. 
• Se os eventos precisarem ser processados no lado do cliente por uma conexão de soquete, não será necessário um wake lock para detectar interrupções de eventos. Quando os pacotes de dados chegam ao rádio Wi-Fi ou celular, o hardware do rádio aciona uma interrupção de hardware na forma de um wake lock do kernel. Em seguida, você pode programar um worker ou adquirir um wake lock para processar os dados.
• Por exemplo, se você estiver usando ktor-network para detectar pacotes de dados em um soquete de rede, só adquira um wake lock quando os pacotes forem entregues ao cliente e precisarem ser processados.

  val readChannel = socket.openReadChannel()
while (!readChannel.isClosedForRead) {
    // CPU can safely sleep here while waiting for the next packet
    val packet = readChannel.readRemaining(1024) 
    if (!packet.isEmpty) {
         // Data Arrived: The system woke the CPU and we should keep it awake via manual wake lock (urgent) or scheduling a worker (non-urgent)
         performWorkWithWakeLock { 
              val data = packet.readBytes()
              // Additional logic to process data packets
         }
    }
}

Resumo

Ao adotar essas soluções recomendadas para casos de uso comuns, como sincronizações em segundo plano, rastreamento de localização, monitoramento de sensores e comunicação de rede, os desenvolvedores podem trabalhar para reduzir o uso desnecessário de wake lock. Para continuar aprendendo, leia nosso outro post técnico no blog ou assista ao vídeo técnico sobre como descobrir e depurar wake locks: Otimize a bateria do app usando a métrica de wake lock do Android vitals. Consulte também nossa documentação atualizada sobre wakelock. Para nos ajudar a continuar melhorando nossos recursos técnicos, compartilhe seu feedback sobre nossas orientações na pesquisa de feedback sobre a documentação.