The Background Battery Vampire

Life360 was draining users' phones from 100% to 30% by midday. A location-tracking app. In the background. All day. The physics were worse than anyone expected.

The Incident

Life360's family location-tracking app required continuous background location updates — by design. But by 2019, user complaints about battery drain had become impossible to ignore. The engineering team built their own power measurement rig using a Monsoon Power Monitor and discovered the true physics of background CPU usage: every wake-sleep cycle was far more expensive than they'd assumed, and their location service was triggering dozens of them per hour.

Evidence from the Scene

Users reported phones dropping from 100% to 30% battery by midday from background location
An idle device draws ~12mW. The same device with Life360 running drew ~70mW — 6x higher
Each CPU wake-sleep cycle spiked to 750mW at peak (195mA × 3.85V)
The background service was triggering 30+ CPU wake events per hour
Battery drain continued even when the device was completely stationary
Disabling Life360 restored normal battery behaviour immediately

The Suspects

2 of these are the real root causes. The others are plausible-sounding distractors.

Partial CPU wake lock held continuously by the background location service

Frequent CPU wake-sleep cycles generating peak power spikes far more expensive than continuous operation

GPS hardware left on continuously between location updates with no duty cycling

Location updates sent at the same rate whether the device was moving or completely stationary

App polling a server endpoint every 60 seconds to check for family member location changes

The Verdict

Real Root Causes

Partial CPU wake lock held continuously by the background location service
A continuous partial wake lock prevents the CPU from entering its low-power sleep state. At 70mW vs 12mW idle, a device with Life360's wake lock running would drain 6x faster than normal — exactly matching the 100% to 30% by midday report. The fix: release the wake lock between location updates and use Android's Significant Motion sensor to suspend updates during device inactivity.
Frequent CPU wake-sleep cycles generating peak power spikes far more expensive than continuous operation
Each CPU wake-sleep cycle spikes to 750mW at peak during the wake transition. At 30+ wake events per hour, the cumulative energy cost of the cycles alone exceeded continuous operation. Batching operations to reduce wake frequency — combined with Doze mode alignment — was the primary architectural fix.

Plausible But Wrong

GPS hardware left on continuously between location updates with no duty cycling
GPS hardware draw is significant — but Life360 used FusedLocationProviderClient which duty cycles the radio appropriately. The dominant cost identified via the Monsoon Power Monitor was CPU wake lock + wake-sleep cycle overhead, not GPS hardware.
Location updates sent at the same rate whether the device was moving or completely stationary
This is a real contributing factor (and was fixed with the Significant Motion sensor) — but it's a secondary optimization. The primary drain came from the wake lock itself and the high-frequency wake cycles.
App polling a server endpoint every 60 seconds to check for family member location changes
Frequent network polling adds radio battery cost — but would not produce the 6x idle power draw described. The 70mW sustained draw is the CPU wake lock signature, not radio polling.

Summary

Life360 discovered that background battery drain has two independent physics: the cost of holding a wake lock (70mW vs 12mW idle = 6x drain), and the cost of frequent wake-sleep cycles (750mW peak per transition × 30+/hour). Their fix: release wake locks between updates, align operations with Android Doze mode windows, use the Significant Motion sensor to suspend updates during device inactivity, and batch tasks to minimize wake frequency. They open-sourced Project Falx — a library that continuously monitors battery impact per feature across releases. This became the reference post-mortem for understanding Android background battery physics.

The Real Decision That Caused This

“Designing a background location service to poll continuously with a persistent wake lock rather than batching updates, aligning with Doze mode, and suspending during device inactivity.”

Lesson Hint

Chapter 7 (Platform & Performance) covers battery optimization, Doze mode, WorkManager constraints, and FusedLocationProviderClient. Chapter 6 (Concurrency) covers coroutine scoping and lifecycle-aware cancellation.

Want to test yourself before reading the verdict?

Open Interactive Case in Autopsy Lab