Crear una app para Android para wearables significa que el trabajo real comienza cuando se apaga la pantalla. WHOOP ayuda a los miembros a comprender cómo responde su cuerpo al entrenamiento, la recuperación, el sueño y el estrés, y, para los muchos miembros de WHOOP en Android, la sincronización y la conectividad confiables en segundo plano son lo que hace posible obtener esas estadísticas.

A principios de este año, Google Play lanzó una nueva métrica en Android vitals: Bloqueos de activación parciales excesivos. Esta métrica mide el porcentaje de sesiones de usuario en las que el uso acumulativo y no exento del bloqueo de activación supera las 2 horas en un período de 24 horas. El objetivo de esta métrica es ayudarte a identificar y abordar las posibles fuentes de agotamiento de la batería, lo que es fundamental para brindar una excelente experiencia del usuario.

A partir del 1 de marzo de 2026, es posible que se excluyan de las plataformas de visibilidad de Google Play las apps que sigan sin cumplir con el umbral de calidad. También es posible que se coloque una advertencia en la ficha de Google Play Store, en la que se indique que la app podría usar más batería de lo esperado.

Según Mayank Saini, ingeniero sénior de Android en WHOOP, esto “le brindó al equipo la oportunidad de mejorar la eficiencia de Android”, después de que Android vitals marcara el porcentaje excesivo de bloqueo de activación parcial de la app en un 15%, lo que superó el umbral recomendado del 5%.

El equipo consideró que la métrica de Android vitals era un indicador claro de que su trabajo en segundo plano mantenía la CPU activa durante más tiempo del necesario. Resolver este problema les permitiría seguir ofreciendo una excelente experiencia del usuario y, al mismo tiempo, reducir el tiempo en segundo plano desperdiciado y mantener una sincronización y conectividad Bluetooth confiables y oportunas.

Cómo identificar el problema

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

Si bien el equipo sabía que WorkManager adquiere un bloqueo de activación mientras ejecuta tareas en segundo plano, anteriormente 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 bloqueos de activación parciales excesivos en Android vitals.

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

Cómo usar las métricas y los datos internos para definir mejor la causa

WHOOP ya tenía una infraestructura interna configurada para supervisar las métricas de WorkManager. Supervisan periódicamente lo siguiente:

1. Tiempo de ejecución promedio: ¿Cuánto tiempo se ejecuta el trabajador?
2. Tiempos de espera agotados: ¿Con qué frecuencia se agota el tiempo de espera del trabajador en lugar de completar la tarea?
3. Reintentos: ¿Con qué frecuencia se reintenta el trabajador si se agotó el tiempo de espera o falló el trabajo?
4. Cancelaciones: ¿Con qué frecuencia se canceló el trabajo?

Hacer un seguimiento de más que solo los éxitos y los errores de los trabajadores le brinda al equipo visibilidad sobre la eficiencia de su trabajo.

Las métricas internas marcaron un tiempo de ejecución promedio alto para unos pocos trabajadores seleccionados, 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 Studio para inspeccionar y depurar los trabajadores de interés, con un enfoque específico en los bloqueos de activación asociados, para alinearse con la métrica marcada en Android vitals.

Investigación: Distinción entre variantes de trabajadores

WHOOP usa la programación única y periódica para algunos trabajadores. Esto permite que la app reutilice la misma lógica de Worker para tareas idénticas con los mismos criterios de éxito, que solo difieren en el tiempo.

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

Este detalle adicional les permitiría 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ó cuando los datos revelaron que ninguna de las variantes parecía contribuir más que la otra.

Manmeet Tuteja, ingeniero de Android II en WHOOP, dijo que “esa división también nos ayudó a confirmar que el problema se producía en ambas variantes, lo que nos indicó que no se trataba de un problema de configuración de la programación, sino de un problema de lógica empresarial compartido dentro de la implementación del trabajador”.

Análisis más detallado del comportamiento de los trabajadores y corrección de la causa raíz

Con el conocimiento de que debían 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. Específicamente, buscaban casos en los que el trabajo podría haberse atascado y no completarse.

Todo esto culminó en el descubrimiento de la causa raíz de los bloqueos de activación excesivos:

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

Si el trabajo comenzó sin un sensor conectado, whoopSensorFlow, que indica si el sensor está conectado, era null. El SensorWorker no trató esto como una condición de salida anticipada y siguió ejecutándose, esperando indefinidamente una conexión. Como resultado, WorkManager mantuvo un bloqueo de activación parcial hasta que se agotó el tiempo de espera del trabajo, lo que provocó un uso elevado del bloqueo de activación en segundo plano y una reprogramación frecuente e innecesaria de SensorWorker.

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

Si el sensor no está disponible, el trabajador sale, lo que evita una situación de tiempo de espera y libera el bloqueo de activación. 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()
            }
}

Lograr una disminución del 90% en las sesiones con bloqueos de activación parciales excesivos

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

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

Como resultado de los cambios, el equipo observó menos casos de agotamiento del tiempo de trabajo sin completar, lo que generó tiempos de ejecución promedio más bajos. 

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

Comenzar ahora

Si te interesa reducir los bloqueos de activación parciales excesivos de tu app o mejorar la eficiencia de los elementos de trabajo, consulta la métrica de bloqueos de activación parciales excesivos de tu app en Android vitals y revisa la documentación sobre bloqueos de activación para obtener más prácticas recomendadas y estrategias de depuración.