The Cache Flood

Users reported Spotify consuming 8–12GB of phone storage. Reinstalling was the only fix. How did a music app eat half a phone's storage?

The Incident

In 2023, Spotify's Android app storage usage became a widely-reported complaint. Users found the app ballooning from a few hundred megabytes to 10GB or more over months of use — even after removing all offline downloads. Android's storage manager showed Spotify as the top offender. The Spotify community forum filled with threads asking why deleting and reinstalling was the only fix.

Evidence from the Scene

App storage grew from ~400MB to 8–12GB over several months of normal use
Removing all offline downloads only freed a fraction of the storage
Reinstalling the app immediately dropped storage back to ~400MB
The bloat occurred even for users who never downloaded music offline
Older Android versions (pre-11) were hit harder and couldn't auto-clear the cache

The Suspects

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

Album art image cache with no maximum size bound — growing indefinitely

Streaming audio segments cached to disk and never cleaned up after playback

No response to Android's onTrimMemory / low-storage broadcast — caches never evicted

Room database storing full song metadata for every track ever played

No TTL on API response cache — stale JSON responses accumulating on disk

Verbose logging writing large log files to disk in production builds

The Verdict

Real Root Causes

Album art image cache with no maximum size bound — growing indefinitely
Every album cover, artist image, and podcast thumbnail fetched during browsing was cached to disk. Without a size cap, this cache accumulated every image ever viewed across months of use — often several gigabytes on its own.
Streaming audio segments cached to disk and never cleaned up after playback
Spotify buffers audio segments ahead of playback for smooth streaming. These temporary files were not reliably deleted after playback ended, accumulating silently over time and accounting for the majority of the unexplained storage.
No response to Android's onTrimMemory / low-storage broadcast — caches never evicted
Android signals apps via ComponentCallbacks2.onTrimMemory() and ACTION_DEVICE_STORAGE_LOW when storage is critically low. Spotify's cache management did not respond to these signals, so the cache grew uninterrupted even when the device had under 1GB free.

Plausible But Wrong

Room database storing full song metadata for every track ever played
A Room database growing unboundedly would contribute megabytes — not gigabytes. The scale of 10GB+ points to binary file caches (images and audio), not relational data.
No TTL on API response cache — stale JSON responses accumulating on disk
JSON response caches with no TTL grow slowly and remain in the kilobytes to low megabytes range — not the 10GB scale described here.
Verbose logging writing large log files to disk in production builds
Production log files are typically capped by Android's logging subsystem and would not produce gigabytes of unexplained storage growth.

Summary

Spotify's Android app was quietly hoarding two types of binary data: album art images cached forever with no size limit, and audio stream segments buffered for playback but never cleaned up. Because neither cache responded to Android's storage pressure callbacks, they grew across months without bound. The fix required implementing an LRU disk cache with a hard size cap for images, a post-playback cleanup job for audio segments, and a ComponentCallbacks2 handler to aggressively evict when the system signaled low storage.

The Real Decision That Caused This

“Implementing disk caches for both images and audio without size bounds, eviction policies, or responses to Android's storage pressure lifecycle signals.”

Lesson Hint

Chapter 5 (Data & Persistence) covers LRU eviction and disk cache sizing strategies. Chapter 7 (Platform & Performance) covers Android lifecycle signals including onTrimMemory.

Want to test yourself before reading the verdict?

Open Interactive Case in Autopsy Lab