Testing Mobile App Interruptions and Lifecycle

A mobile app never runs in a vacuum. While the user is in it, the operating system interrupts at any moment: a call, a push, backgrounding, low memory, a screen rotation. And it’s at these seams that the most painful bugs hide — the ones a calm manual run never shows. Let’s look at what to test here and how.

Interruptions

Something happens on top of your action — the app must survive it:

An incoming call right during payment/input/gameplay — you return, is the state intact?
A push notification and a tap on it from mid-flow — where does it lead, does it break the current screen?
Alarm, timer, notification shade, Control Center.
Split-screen / multi-window, picture-in-picture.
Biometrics (Face ID / fingerprint) over the screen — payment confirmation, auto-lock.
In games: backgrounding mid-match/animation/loading — did anything fall apart?

Lifecycle and process kill

The most common hole. You background the app → the OS kills the process for memory → the user comes back:

Does the app restore state (same screen, entered data, position) rather than start from scratch?
Are unsaved data (form draft, cart, progress) not lost?
Are the token/session still alive or renewed correctly?
Android: reproduce via Developer Options → “Don’t keep activities” (the OS kills the activity immediately on backgrounding). A classic catcher of restore bugs.
iOS: a suspended app can be terminated — check both a cold and a “warm” return.

Rotation

Rotation recreates the screen (on Android — the Activity): is entered text, list state, an open dialog preserved?
Layout doesn’t break in landscape; nothing is clipped.
Rotation during a request/animation/dialog.

Network

Mobile networks are unstable by design — you have to provoke it:

A drop mid-request (you submit a form, the network dies): it didn’t hang, showed an error, offered a retry.
Switching wifi ↔ LTE, airplane mode and back.
Slow network (2G/high latency) — timeouts, spinners, no freeze.
Duplicates on retries — a drop + retry doesn’t create two records/two payments (idempotency).
Offline mode — what’s available without a network, correct sync on return.

Device resources

Low-memory kill — under memory pressure the OS kills the background (see lifecycle).
Battery saver / Low Power mode — background tasks, push, sync get throttled.
Throttling and heat (especially games) — FPS drop, behavior on overheating.
No disk space — download/cache/save: a clear error, not a crash.
Discharge/charging, an incoming event during a heavy operation.

Permissions

The user revoked a permission (camera, location, mic, notifications) in settings while the app was backgrounded → they return: the app doesn’t crash, it re-requests/degrades gracefully.
First denial and “don’t ask again.”
On-the-fly changes to system settings (theme, language, font size).

How to reproduce it

Android adb: kill the process adb shell am kill <pkg>, Developer Options “Don’t keep activities”, “Background process limit”.
Network: airplane mode/toggles, Network Link Conditioner (iOS/macOS), emulate 2G/loss in the emulator or a throttling proxy.
Interruptions: a real call/push; on the emulator — extended controls (call, rotate, battery).
Real devices matter more than the emulator for memory/network/heat — but the emulator is handy for quick edge cases.
Keep a short interruptions checklist and run it across key screens (payment, form, game, onboarding).

In short

Bugs live at the seam with the OS: call/push/backgrounding/rotation/network/memory.
The main hole is background process kill: the return must restore state, not start from scratch (Android “Don’t keep activities”).
Rotation recreates the screen — check that input is preserved.
Provoke the network: mid-request drop, wifi↔LTE, slow, duplicates on retries, offline.
Resources: low-memory kill, battery saver, no space, heat.
Permissions can be revoked in the background — don’t crash.
Reproduce with adb/Network Link Conditioner + real devices; keep an interruptions checklist.