The GPS Vampire

Driver phones were dying mid-shift. Passengers were being stranded. The culprit was invisible.

The Incident

Uber drivers in 2015–2016 reported their phones overheating and dying mid-shift even when plugged into car chargers. Crash reports showed memory growing throughout a shift with no clear ceiling. Location updates became choppy after two hours. Engineers had to investigate what was consuming so much power in an app that was fundamentally just tracking location.

Evidence from the Scene

Phone battery drained 30–40% per hour even while plugged into a car charger
Location updates became choppy and irregular after 2+ hours online
Memory usage grew linearly throughout a shift, never returning to baseline
Device temperature spiked within 20 minutes of going online
Crash logs revealed multiple LocationListener instances active simultaneously

The Suspects

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

Using LocationManager directly instead of FusedLocationProviderClient

LocationListener not removed in onStop() — leaking across Activity restarts

GPS update interval fixed at 1 second regardless of vehicle speed or driver state

Google Maps SDK re-rendering the full map on every location update

Coroutines not cancelled when the ViewModel is cleared

Retrofit making synchronous network calls on the main thread

The Verdict

Real Root Causes

Using LocationManager directly instead of FusedLocationProviderClient
Raw LocationManager requests the GPS hardware directly at full power. FusedLocationProvider batches and optimizes location requests across all apps on the device, dramatically reducing power draw by using cell towers and Wi-Fi alongside GPS.
LocationListener not removed in onStop() — leaking across Activity restarts
Each screen rotation or app backgrounding created a new LocationListener without unregistering the previous one. After 30 minutes of driving, dozens of listeners were all receiving and processing GPS updates simultaneously — explaining the linear memory growth and battery drain.
GPS update interval fixed at 1 second regardless of vehicle speed or driver state
1-second intervals are justified only when the driver is actively moving. When stationary at a red light or waiting for a ride request, the same interval wastes significant power. Adaptive intervals based on detected speed cut battery usage by up to 60%.

Plausible But Wrong

Google Maps SDK re-rendering the full map on every location update
Map rendering is GPU-bound and visible on screen — it causes frame drops and UI jank, not the invisible background heat and drain described here.
Coroutines not cancelled when the ViewModel is cleared
Uncancelled coroutines can leak objects, but they do not activate GPS hardware or produce the device heat described in the clues.
Retrofit making synchronous network calls on the main thread
Synchronous main-thread network calls cause ANRs and UI freezes — not the gradual battery drain, heat buildup, and memory growth described here.

Summary

The Uber Driver app was fighting Android's power management at the hardware level. By using LocationManager directly, every GPS request hit the physical chip at full power with no OS-level batching or optimization. The listener leak meant every Activity restart added a new subscriber without removing the old one — after a 4-hour shift, the device was running dozens of parallel GPS pipelines. The fix was migrating to FusedLocationProviderClient, binding listeners to the Activity lifecycle via a lifecycle-aware component, and implementing adaptive polling intervals that slow down when the vehicle is stationary.

The Real Decision That Caused This

“Bypassing Android's location optimization layer (FusedLocationProvider) while also leaking location listeners across lifecycle events due to no lifecycle-aware architecture.”

Lesson Hint

Chapter 7 (Platform & Performance) covers FusedLocationProvider and battery-efficient location patterns. Chapter 2 (App Architecture) covers lifecycle-aware components that prevent listener leaks.

Want to test yourself before reading the verdict?

Open Interactive Case in Autopsy Lab