Interruption Testing in a Mobile Game: A Call, a Backgrounded App, and a Lost Session

I once had a bug that wouldn’t reproduce in any review: players wrote “match progress disappeared.” Turned out — if a call came in during a battle, the game backgrounded, and on resume it started a new session: the unsaved move was lost, and for some people the audio then went silent too. On my test device everything was perfect — because I don’t call myself in the middle of a test.

A mobile game doesn’t live in a vacuum: at any moment a call, a push, the notification shade, an alarm, an ad pops up over it. An interruption isn’t a rare edge case, it’s a normal part of a user session. And what you test isn’t “does the game work,” it’s “does it survive being rudely paused and resumed.”

Why interruptions are a minefield

When an app goes to the background, the OS runs it through its lifecycle (onPause/onStop on Android, sceneWillResignActive/didEnterBackground on iOS, OnApplicationPause/OnApplicationFocus in Unity). On resume it all unwinds back. Bugs live exactly in those transitions: something wasn’t saved on the way out, something wasn’t restored on the way in, something kept spinning in the background when it shouldn’t.

And the same rule applies as with real devices: on your phone, where you never interrupt yourself, these bugs don’t exist. You have to provoke them deliberately.

The catalog of interruptions (what to provoke)

Incoming call — the classic. The game backgrounds, audio should duck/pause.
System notification / push — a top banner, the notification shade.
Backgrounding — Home, swipe to “recents,” switching to another app.
Screen lock — the power button, auto-lock on timeout.
Low battery and power saving — Low Power Mode / aggressive vendor background killing (Xiaomi, Samsung, Oppo kill the process).
Incoming ad — an interstitial/rewarded opens its own activity over the game: this is an interruption too, and the nastiest one (see below).
Headphones / Bluetooth — plugged in, unplugged, a BT drop mid-audio.
Split-screen / Picture-in-Picture / floating window — the game loses full focus but stays visible.
Alarm, timer, a second incoming call, calendar — system overlays.
Screenshot / screen recording / sharing — a brief focus loss.
Network switch — Wi-Fi ↔ cellular on backgrounding (a frequent companion of interruptions).

What actually breaks on resume

Loss of unsaved progress. A move, an unfinished match, entered text, a position in the tutorial. If state isn’t saved in onPause, it’s gone.
Audio didn’t come back or didn’t mute. After a call the music is silent; or the reverse — during the call the game blasts into the earpiece. Check audio focus.
Rewarded ad: reward lost or doubled. Background the app during the video, come back — the reward never arrived (or arrived twice). That’s direct damage to both trust and money.
The multiplayer session dropped. Reconnect didn’t fire, the player got kicked from the match, rating dropped; or the reverse — “stuck” in the room.
Background timers lied. In-game timers (energy, dailies, boosts) either froze or, conversely, kept ticking and opened a cheat via system-clock manipulation.
Double onResume / black screen on resume. The game initializes twice, hits a race, shows a black screen or crashes.
The pause dialog/menu didn’t appear. The game didn’t pause on backgrounding — the battle continued without the player.

iOS and Android — different behavior

Android is more aggressive about killing the background: the system (or a vendor battery saver) can terminate the process, and resume = a cold start with state restoration. Always test the “process killed in background → resume” scenario.
iOS is gentler with memory but stricter with background time: an app gets mere seconds to finish work in the background.
Unity/engine adds its own layer: OnApplicationPause(true/false) and OnApplicationFocus don’t always fire the way you expect (especially with ads and split-screen) — test on real hardware, not in the editor.

How to reproduce (instead of hoping)

A real incoming call from another phone at the moment of an active action.
adb shell am start -a android.intent.action.CALL / an emulated call in the emulator; but final acceptance — on a real device.
Background to Home and kill the process from “recents” (or adb shell am kill <package>), then return — the “process killed in background” check.
Turn on Low Power Mode and a vendor battery saver, leave in the background for minutes.
Interrupt EXACTLY at critical moments: during a save, mid rewarded-video, on the deciding move, at the moment of a network request.
Every case on varied hardware (see the device matrix), especially on vendors with aggressive killing.

Interruption checklist

In short — what to take with you

An interruption is a normal part of a session, not a rare edge case. Provoke it deliberately.
Bugs live in the lifecycle transitions: not saved on the way out, not restored on the way in.
The three most expensive cases: lost progress, a lost/doubled rewarded reward, a dropped multiplayer session.
Always test “process killed in background” (especially Android + vendor killing) and interrupting EXACTLY at a critical moment.
Real devices and a real call — the emulator won’t show half of this.

Further reading: Android — the Activity lifecycle · Apple — managing your app’s life cycle · Unity — OnApplicationPause