Member-only story
When the OS Pulls the Plug: Android State That Survives Process Death
Not a Medium Member? “Read For Free”
Your app works on your phone. It crashes for users who switch apps for ten minutes.
Rotation is not the same as process death. Most apps pass the first and fail the second, and the gap between them is where a surprising share of “cannot reproduce” crash reports live.
Here is the pattern. A user opens your checkout flow, gets a text message, replies, checks a map, and comes back eleven minutes later. Meanwhile the system needed memory for the camera and quietly killed your process. When the user returns, Android rebuilds your Activity from a small saved Bundle into a brand-new process. Every object you were holding in memory is gone. If any screen assumed it was still there, you get a NullPointerException, an empty screen, or worse, a form that silently resets.
This post covers what actually happens, how to trigger it on demand, and how to design state so the app comes back whole.
1. Two different events
A configuration change and process death both end with your Activity being constructed again, which is why they get confused. They are very different underneath.
