How WHOOP Decreased Excessive Partial Wake Lock Sessions by Over 90%
Article Summary
WHOOP's Android team turned a Google Play compliance warning into a masterclass in battery optimization. Their excessive wake lock sessions dropped from 15% to under 1% in just 30 days.
When Google Play flagged WHOOP's app for exceeding the 5% threshold on excessive partial wake locks (they were at 15%), the team had to act fast. Starting March 2026, non-compliant apps face exclusion from Play Store discovery and battery drain warnings on their listings.
Key Takeaways
- Android vitals dashboard pinpointed WorkManager as the main wake lock culprit
- Internal metrics tracked worker runtime, timeouts, retries, and cancellations for visibility
- Used setTraceTag to distinguish periodic vs one-time worker variants during debugging
- Root cause: CoroutineWorker waiting indefinitely for sensor connection without early-exit logic
- Fix reduced excessive wake lock sessions by over 90% within 30 days
By combining Android vitals data with internal metrics and Background Task Inspector, WHOOP identified a stuck CoroutineWorker and reduced excessive wake locks from 15% to under 1%.
About This Article
WHOOP couldn't see how background work was distributed across tasks in WorkManager. This made it impossible to figure out which workers were draining the battery with excessive wake locks until Android vitals added a new metric.
WHOOP used WorkManager's setTraceTag method to separate one-time workers from periodic ones. This revealed the real problem: a CoroutineWorker with shared business logic that waited indefinitely for sensor connection and had no way to exit early.
WHOOP added an early-exit check for sensor availability before running the core logic. Excessive partial wake lock sessions dropped from 15% to less than 1% within 30 days.