Crear una aplicación Android para un wearable significa que el trabajo de verdad empieza cuando se apaga la pantalla. WHOOP ayuda a sus miembros a entender cómo responde su cuerpo al entrenamiento, la recuperación, el sueño y el estrés. Para los muchos miembros de WHOOP que usan Android, la sincronización y la conectividad fiables en segundo plano son lo que hace posibles esos insights.

A principios de este año, Google Play lanzó una nueva métrica en Android vitals: wake locks parciales excesivos. Esta métrica mide el porcentaje de sesiones de usuario en las que el uso acumulativo de wake locks no exentos supera las 2 horas en un periodo de 24 horas. El objetivo de esta métrica es ayudarte a identificar y solucionar posibles fuentes de consumo de batería, lo cual es fundamental para ofrecer una experiencia de usuario de calidad.

A partir del 1 de marzo del 2026, las aplicaciones que sigan sin alcanzar el umbral de calidad podrán excluirse de las superficies de descubrimiento de Google Play. También puede que se muestre una advertencia en la ficha de Google Play Store, en la que se indique que la aplicación podría usar más batería de lo esperado.

Según Mayank Saini, ingeniero sénior de Android en WHOOP,  esto "dio al equipo la oportunidad de mejorar la eficiencia de Android" después de que Android vitals detectara que el porcentaje de wake locks parciales excesivos de la aplicación era del 15 %, lo que superaba el umbral recomendado del 5 %.

El equipo consideró que la métrica Android vitals era una señal clara de que el trabajo en segundo plano mantenía la CPU activa más tiempo del necesario. Si se resuelve este problema, podrán seguir ofreciendo una experiencia de usuario excelente y, al mismo tiempo, reducir el tiempo de inactividad en segundo plano y mantener una conectividad y sincronización Bluetooth fiables y oportunas.

Identificar el problema

Para saber por dónde empezar, el equipo recurrió a Android vitals para obtener más información sobre qué bloqueos de activación afectaban a la métrica. Al consultar el panel de control de wake locks parciales excesivos de Android vitals, pudieron identificar que el principal factor que contribuía a los wake locks parciales excesivos era uno de sus elementos de trabajo de WorkManager (identificado en el panel de control como androidx.work.impl.background.systemjob.SystemJobService). Para ofrecer la experiencia de WHOOP, la aplicación usa WorkManager para tareas en segundo plano, como la sincronización periódica y el envío de actualizaciones recurrentes al wearable. 

Aunque el equipo sabía que WorkManager adquiere un wake lock mientras ejecuta tareas en segundo plano, antes no tenía visibilidad de cómo se distribuía todo su trabajo en segundo plano (más allá de WorkManager) hasta que se introdujo la métrica de wake locks parciales excesivos en Android vitals.

Como el panel de control identificó WorkManager como el principal colaborador, el equipo pudo centrar sus esfuerzos en identificar cuál de sus workers contribuía más y trabajar para resolver el problema.

Usar métricas y datos internos para acotar mejor la causa

WHOOP ya había configurado una infraestructura interna para monitorizar las métricas de WorkManager. Monitorizan periódicamente lo siguiente:

1. Tiempo de ejecución medio: ¿cuánto tiempo se ejecuta el trabajador?
2. Tiempos de espera: ¿con qué frecuencia se agota el tiempo de espera del trabajador en lugar de completar la tarea?
3. Reintentos: ¿con qué frecuencia vuelve a intentar el trabajador si se agota el tiempo de espera o se produce un error?
4. Cancelaciones: ¿con qué frecuencia se canceló el trabajo?

Si se hace un seguimiento de los éxitos y los fracasos de los trabajadores, el equipo puede ver la eficiencia de su trabajo.

Las métricas internas indicaron un tiempo de ejecución medio alto en el caso de unos pocos trabajadores, lo que les permitió acotar aún más la investigación. 

Además de sus métricas internas, el equipo también usó el inspector de tareas en segundo plano de Android Studiopara inspeccionar y depurar los workers de interés, centrándose en los bloqueos de activación asociados, para alinearse con la métrica marcada en Android vitals.

Investigación: distinguir entre variantes de trabajadores

WHOOP usa la programación única y la periódica para algunos trabajadores. De esta forma, la aplicación puede reutilizar la misma lógica de Worker para tareas idénticas con los mismos criterios de éxito, que solo difieren en el tiempo.

Gracias a sus métricas internas, pudieron acotar la búsqueda a un trabajador específico, pero no pudieron determinar si el error se producía cuando el trabajador era único, periódico o ambos. Por eso, lanzaron una actualización para usar el método setTraceTag de WorkManager para distinguir entre las variantes únicas y periódicas del mismo Worker.

Estos detalles adicionales les permitirían identificar de forma definitiva qué variante de Worker (periódica o única) contribuía más a las sesiones con bloqueos de activación parcial excesivos. Sin embargo, el equipo se sorprendió al descubrir que ninguna de las variantes parecía contribuir más que la otra.

Manmeet Tuteja, ingeniero de Android II de WHOOP, explica que "esta división también nos ayudó a confirmar que el problema se producía en ambas variantes, lo que nos hizo descartar que se tratara de un problema de configuración de la programación y nos llevó a pensar que era un problema de lógica empresarial compartida en la implementación del trabajador".

Analizar en profundidad el comportamiento de los trabajadores y solucionar la causa principal

Sabiendo que tenían que analizar la lógica dentro del trabajador,  el equipo volvió a examinar el comportamiento de los trabajadores que se habían marcado durante la investigación. En concreto, buscaban casos en los que el trabajo se quedara bloqueado y no se completara.

Todo esto culminó en el descubrimiento de la causa principal de los wake locks excesivos:

Un CoroutineWorker diseñado para esperar a que se establezca una conexión con el sensor WHOOP antes de continuar. 

Si el trabajo se inició sin ningún sensor conectado, whoopSensorFlow, que indica si el sensor está conectado, era null. SensorWorker no lo trató como una condición de salida anticipada y siguió ejecutándose, por lo que esperó indefinidamente a que se estableciera una conexión. Como resultado, WorkManager mantuvo un wake lock parcial hasta que se agotó el tiempo de espera del trabajo, lo que provocó un uso elevado del wake lock en segundo plano y una reprogramación frecuente e innecesaria de SensorWorker.

Para solucionar este problema, el equipo de WHOOP actualizó la lógica del trabajador para comprobar el estado de la conexión antes de intentar ejecutar la lógica empresarial principal.

Si el sensor no está disponible, el trabajador se cierra, lo que evita que se agote el tiempo de espera y libera el wake lock. En el siguiente fragmento de código se muestra la solución:

  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()
            }
}

Reducir en un 90% las sesiones con wake locks parciales excesivos

Después de lanzar la corrección, el equipo siguió monitorizando el panel de control de Android vitals para confirmar el impacto de los cambios. 

En última instancia, WHOOP observó que el porcentaje excesivo de bloqueo parcial de activación se redujo del 15% a menos del 1% en tan solo 30 días después de implementar los cambios en su trabajador. 

Como resultado de los cambios, el equipo ha observado menos casos en los que el trabajo se agota sin completarse, lo que ha provocado que los tiempos de ejecución medios sean más bajos. 

El consejo del equipo de WHOOP para otros desarrolladores que quieran mejorar la eficiencia de su trabajo en segundo plano:

Empezar

Si quieres reducir los wake locks parciales excesivos de tu aplicación o mejorar la eficiencia de los elementos de trabajo, consulta la métrica de wake locks parciales excesivos de tu aplicación en Android vitals y lee la documentación sobre wake locks para obtener más información sobre las prácticas recomendadas y las estrategias de depuración.