The Wake Lock Enforcement

CoroutineWorkers suspending indefinitely on StateFlow.first() or similar operators when preconditions weren't met

StateFlow.filterNotNull().first() or Channel.receive() inside a CoroutineWorker's doWork() suspends the coroutine — and WorkManager's internal wake lock — until an emission arrives. If the emission never comes (device offline, sensor disconnected, state permanently null), the worker holds the wake lock until WorkManager's maximum execution time and reschedules, repeating indefinitely.

PowerManager.WakeLock.acquire() called without a timeout — wake lock never released on failure path

acquire() without a timeout parameter creates a wake lock that must be manually released. If the code path to release() is guarded by a condition that isn't met (exception, early return, state mismatch), the wake lock is held forever. The fix: always use acquire(timeoutMillis) or wrap in try/finally.

PeriodicWorkRequest set to 15-minute intervals for tasks that could safely run hourly or daily

Over-scheduled periodic work increases wake frequency and cumulative battery cost — a real concern — but it produces many short workers, not the 2+ hour session accumulation that triggers the excessive wake lock metric. The indefinite suspension pattern is the dominant cause of that metric.

WorkManager tasks running without setRequiresBatteryNotLow(true) during low battery

Missing battery constraints allow work to run when battery is low — a consideration for scheduling strategy, but not the cause of the excessive wake lock metric. The metric is about session duration of wake lock accumulation, not scheduling frequency.

SensorManager registered with maxReportLatencyUs = 0, disabling sensor hardware batching

Disabling sensor batching increases CPU wake frequency for sensor data delivery — a secondary battery concern. The excessive partial wake lock metric is primarily driven by workers that suspend indefinitely, not sensor sampling frequency.