Criar um app Android para um wearable significa que o trabalho de verdade começa quando a tela é desligada. WHOOP ajuda os membros a entender como o corpo responde ao treinamento, recuperação, sono e estresse. Para os muitos membros da WHOOP no Android, a sincronização e a conectividade confiáveis em segundo plano são o que tornam esses insights possíveis.

No início deste ano, o Google Play lançou uma nova métrica no Android vitals: wake locks parciais em excesso. Essa métrica mede a porcentagem de sessões de usuários em que o uso cumulativo de wake locks não isentos excede 2 horas em um período de 24 horas. O objetivo dessa métrica é ajudar você a identificar e resolver possíveis fontes de consumo elevado da bateria, o que é essencial para oferecer uma ótima experiência do usuário.

A partir de 1º de março de 2026, os apps que não atenderem ao limite de qualidade poderão ser excluídos das plataformas de descoberta do Google Play. Um aviso também poderá ser colocado na página de detalhes do app na Google Play Store, indicando que ele pode usar mais bateria do que o esperado.

De acordo com Mayank Saini, engenheiro sênior do Android na WHOOP, isso "apresentou à equipe uma oportunidade de elevar o nível de eficiência do Android", depois que o Android vitals sinalizou a porcentagem excessiva de wake locks parciais do app como 15%, o que excedeu o limite recomendado de 5%.

A equipe considerou a métrica do Android vitals como um sinal claro de que o trabalho em segundo plano estava mantendo a CPU ativa por mais tempo do que o necessário. A resolução desse problema permitiria que eles continuassem oferecendo uma ótima experiência do usuário, diminuindo o tempo de segundo plano desperdiçado e mantendo a conectividade e a sincronização Bluetooth confiáveis e oportunas.

Identificação do problema

Para descobrir por onde começar, a equipe primeiro recorreu ao Android vitals para ter mais insights sobre quais wake locks estavam afetando a métrica. Ao consultar o painel de wake locks parciais em excesso do Android vitals, eles puderam identificar o maior colaborador de wake locks parciais em excesso como um dos workers do WorkManager (identificado no painel como androidx.work.impl.background.systemjob.SystemJobService). Para oferecer suporte à "experiência sempre ativa" da WHOOP, o app usa o WorkManager para tarefas em segundo plano, como sincronização periódica e entrega de atualizações recorrentes ao wearable. 

Embora a equipe estivesse ciente de que o WorkManager adquire um wake lock ao executar tarefas em segundo plano, eles não tinham visibilidade de como todo o trabalho em segundo plano (além do WorkManager) era distribuído até a introdução da métrica de wake locks parciais em excesso no Android vitals.

Com o painel identificando o WorkManager como o principal colaborador, a equipe pôde concentrar os esforços na identificação de qual dos workers estava contribuindo mais e trabalhar para resolver o problema.

Uso de métricas e dados internos para restringir melhor a causa

A WHOOP já tinha uma infraestrutura interna configurada para monitorar as métricas do WorkManager. Eles monitoram periodicamente:

1. Tempo de execução médio: por quanto tempo o worker é executado?
2. Tempos limite: com que frequência o worker atinge o tempo limite em vez de ser concluído?
3. Novas tentativas: com que frequência o worker tenta novamente se o trabalho atingir o tempo limite ou falhar?
4. Cancelamentos: com que frequência o trabalho foi cancelado?

O acompanhamento de mais do que apenas sucessos e falhas do worker oferece à equipe visibilidade da eficiência do trabalho.

As métricas internas sinalizaram tempo de execução médio alto para alguns workers selecionados, permitindo que eles restringissem ainda mais a investigação. 

Além das métricas internas, a equipe também usou o Inspetor de tarefas em segundo plano do Android Studio para inspecionar e depurar os workers de interesse, com foco específico nos wake locks associados, para se alinhar à métrica sinalizada no Android vitals.

Investigação: distinção entre variantes de worker

A WHOOP usa o agendamento único e periódico para alguns workers. Isso permite que o app reutilize a mesma lógica de worker para tarefas idênticas com os mesmos critérios de sucesso, diferindo apenas no tempo.

O uso das métricas internas possibilitou restringir a pesquisa a um worker específico, mas eles não puderam dizer se o bug ocorreu quando o worker era único, periódico ou ambos. Então, eles lançaram uma atualização para usar o método setTraceTag do WorkManager para distinguir entre as variantes únicas e periódicas do mesmo worker.

Esse detalhe extra permitiria que eles identificassem definitivamente qual variante de worker (periódica ou única) estava contribuindo mais para sessões com wake locks parciais em excesso. No entanto, a equipe ficou surpresa quando os dados revelaram que nenhuma variante parecia contribuir mais do que a outra.

Manmeet Tuteja, engenheiro do Android II na WHOOP, disse que "essa divisão também nos ajudou a confirmar que o problema estava acontecendo nas duas variantes, o que apontou para um problema de lógica de negócios compartilhada dentro da implementação do worker, e não para a configuração de agendamento".

Aprofundamento no comportamento do worker e correção da causa raiz

Com o conhecimento de que precisavam analisar a lógica dentro do worker,  a equipe reexaminou o comportamento dos workers que haviam sido sinalizados durante a investigação. Especificamente, eles estavam procurando instâncias em que o trabalho poderia ter ficado preso e não concluído.

Tudo isso culminou na descoberta da causa raiz dos wake locks em excesso:

Um CoroutineWorker projetado para aguardar uma conexão com o sensor WHOOP antes de continuar. 

Se o trabalho começasse sem um sensor conectado, whoopSensorFlow, que indica se o sensor está conectado, seria null. O SensorWorker não tratou isso como uma condição de saída antecipada e continuou em execução, aguardando indefinidamente uma conexão. Como resultado, o WorkManager manteve um wake lock parcial até que o trabalho atingisse o tempo limite, levando a um alto uso de wake lock em segundo plano e a um reagendamento frequente e indesejado do SensorWorker.

Para resolver esse problema, a equipe da WHOOP atualizou a lógica do worker para verificar o status da conexão antes de tentar executar a lógica de negócios principal.

Se o sensor não estiver disponível, o worker será encerrado, evitando um cenário de tempo limite e liberando o wake lock. O snippet de código a seguir mostra a solução:

  class SensorWorker(appContext: Context, params: WorkerParameters): CoroutineWorker(appContext, params) {
   override suspend fun doWork(): Result {
      ...
      // Check the sensor state and perform work or return failure
       return whoopSensorFlow.replayCache
            .firstOrNull()
            ?.let { cachedData ->
                processSensorData(cachedData)
                Result.success()
            } ?: run {
                Result.failure()
            }
}

Como alcançar uma diminuição de 90% nas sessões com wake locks parciais em excesso

Depois de lançar a correção, a equipe continuou monitorando o painel do Android vitals para confirmar o impacto das mudanças. 

Por fim, a WHOOP observou que a porcentagem de wake locks parciais em excesso caiu de 15% para menos de 1% apenas 30 dias após a implementação das mudanças no worker. 

Como resultado das mudanças, a equipe observou menos instâncias de tempo limite de trabalho sem conclusão, resultando em tempos de execução médios mais baixos. 

O conselho da equipe da WHOOP para outros desenvolvedores que querem melhorar a eficiência do trabalho em segundo plano:

Primeiros passos

Se você quiser tentar reduzir os wake locks parciais em excesso do seu app ou melhorar a eficiência do worker, consulte a métrica de wake locks parciais em excesso do app em Android vitals e revise a documentação de wake locks para conferir mais práticas recomendadas e estratégias de depuração.