The process can be killed at any moment
Aliases: process death · background reclamation · LMK · cached process
What it is
Process death is the OS ending the app process without the person closing it: memory pressure, OEM background killers, an OS update, a swipe from the recents switcher, a long stay off-screen. The card in the recents UI is a snapshot of the last frame, not proof the process is alive. A call, a one-time code, a jump into Camera, and the original app may already be gone from memory. This entry is the fact that the process can vanish at any time. It is not about which screen to restore on return, and not about how typed text gets onto disk.
Why it happens
Mobile systems rank processes: foreground, visible, service, cached. When RAM is short, cached processes go first. The low-memory killer does not queue a thirty-second warning. OEM battery policies add silent kills whose timing the app never sees. Recents caches a screenshot and a task description, which is enough to sustain the illusion that the app is "still open," so people treat the card as the process. Swiping a card is an explicit kill on some systems and only a forget-the-task on others; the gestures look alike, the lifetime results do not. Any session kept only in process memory is betting on an unpredictable scheduler.
Studying it
Use field logs and controlled kills, not "switch away and back" on a USB-powered lab phone.
Independent variables: time off-screen, foreground memory pressure (Camera or a browser open), swipe-from-recents versus ordinary switch, OEM battery mode. Dependent variables: whether the process is still alive, cold-start rate, reports of "I thought it was still open," frequency of force-stop.
Lab devices with spare RAM and OEM killers disabled undercount death. A survey item about swiping recents measures a mental model, not actual lifetime; pair it with OS process-lifetime logs. Do not read "people clear recents" as battery anxiety alone—some use the swipe to confirm a task has ended.
Where it stops holding
Work marked as a foreground service (navigation, a call, recording) is more kill-resistant under ordinary policy; that protection does not extend to ordinary screens. A debug build on cable with sleep disabled almost never dies, which fabricates the claim that switching away is safe. Desktop memory pressure is a different model: a covered window is not a reclaimed process. An explicit quit or sign-out ends the session on purpose and must not be restored as "still in use."
Applying it
- Treat "the process can vanish" as the default: any session that lives only in RAM is a session that will be lost.
- Do not treat the recents screenshot as a progress promise; the card can outlive the process.
- Verify on a device off charger, with Camera or a browser holding RAM. Switch the app to the background for two minutes, then confirm with system tools whether the process is alive. For every death, check whether the product treated it as an ordinary pause.