Most Android apps save UI state, but very few can explain what happened after the process dies. SavedStateHandle can put the user back on a screen, but it does not tell you why the app died, what operation was interrupted, or whether the app should retry, recover, or ignore the previous session. This session shows a practical postmortem pattern for Android process death. We will use SavedStateHandle for UI restoration, setProcessStateSummary as a tiny operation note, and ApplicationExitInfo as the death record read on next launch. Then we will compare that pattern against real device experiments: Recents swipe, am kill, SIGKILL, reboot, and lmkd memory pressure. We will also connect this to Android 17 app memory limits, where some memory kills are reported as REASON_OTHER and the useful clue lives in ApplicationExitInfo.getDescription(). The goal is not to replace Crash analytics It is to add the domain-specific recovery state those tools cannot infer: what work died with the process, and what the app should do next. Attendees will leave with a small implementation pattern they can add to existing apps and crash-reporting pipelines.