When your app is in the background, Android can end its process to free memory, with no warning and no crash report. The user switches back and expects to continue where they left off. If your state lived only in memory, they land on the start screen with their input gone. This bug is common because it never happens on a developer phone with plenty of free memory, and it is easy to reproduce on demand.
Two ways to simulate it
Option 1: Don't keep activities. In Developer options (tap Build number in About phone seven times to unlock them), turn on Don't keep activities. Each screen you leave is destroyed. Remember to turn it off afterwards. It tests screen recreation, which is a close cousin of process death.
Option 2: Kill the process. Put the app in the background (home button, not swipe-away from recents), then run from a computer with adb:
adb shell am kill <your.package.name>
Then reopen the app from recents. The command only ends a process that is in the background; if nothing happens, the app was still in the foreground. Swiping the app away in recents is a user force-stop, which is a different case: the system does not restore state after it.
Checklist
Run each case, kill the process, return, and compare.
- Form with typed text. Expect: input is still there, or the user is told clearly what was lost.
- Deep screen. Open a detail screen three levels down. Expect: you return to that screen, not the start.
- Scroll position and tab. Expect: same tab, roughly same place.
- Selected items and filters. Expect: selection and active filter remain.
- Multi-step flow such as onboarding, checkout or setup wizard. Expect: the step and earlier answers remain. This is where users lose the most.
- Open dialog or bottom sheet. Expect: either restored or cleanly closed, never half-drawn.
- Logged-in state. Expect: the user stays signed in.
- Running tasks. Upload, download, timer. Expect: resumes, restarts safely, or shows a clear failure, without duplicates.
- Permission or system screen detour. Leave to a system dialog, kill, return. Expect: the app continues the flow.
- Deep link or share intent. Launch from a link, kill, return. Expect: correct screen.
- Cold start after a long time. Leave the app for hours, return. Expect: it starts without crashes from stale data.
What to report
Steps before the kill, the exact method used, what the user saw on return, and the screen name. Mention if the device had low memory, since it can trigger this naturally.
Fixing
Save what the user would miss, in the places Android provides for saved state, and keep durable data in storage rather than memory. Re-test with the same steps.
Limits
Real low-memory behavior differs between devices. The simulation checks your handling, not how often the system will do it.
Overview: Android app testing. Related: rotation and configuration changes and battery saver and Doze.
Start free on AppReviewX and get testers to run these steps and report in a structured way.