Interruptions (Calls, SMS, Alarms)

Maya is paying for concert tickets in her banking app. She types €25.00, adds a note, taps Send, and her phone rings. It’s her mom. She declines, goes back to the app, sees the spinner still turning and the form looking oddly empty. A minute later she gets two “Payment sent” notifications. She paid twice.

Nobody on the team had ever tested “phone call during a payment”. On a desk with a test phone, nobody calls you. In real life, people get calls, messages and alarms in the middle of everything.

Why it matters

An interruption is anything that pulls the user, the screen or the audio away from your app for a moment. Your app doesn’t choose when that happens, and it can’t stop it. It can only react well.

Interruption bugs are nasty because:

They lose real things: a typed form, workout progress, a video position, sometimes money.
They don’t show up in normal testing. You have to cause them on purpose.
Users blame the app, not the phone call. “The app deleted my message” ends up in a one-star review.

The good news: once you know the list of interruptions and the four things that should happen, testing them is quick and very rewarding.

Types of interruptions

Not all interruptions are equal. Some only cover part of the screen, some take over the audio, some send the app to the background completely.

Interruption	What the phone does	What a well-behaved app does
Incoming call (ringing)	Full-screen call UI or a banner. Ringtone plays.	Pause video and audio. Keep the screen state.
Call accepted	Call audio takes over. The app goes to the background.	Stay paused. Save drafts. Don’t time out the session too early.
Call declined / missed	You’re back in the app within seconds.	Everything exactly as it was. No double actions.
SMS / notification banner	A banner slides over the top for a few seconds.	Nothing. The app keeps running. Content stays usable.
Alarm or timer	Full-screen alarm and loud sound.	Pause media. Resume cleanly when the alarm is stopped.
Low battery alert / Low Power Mode	A system alert. Low Power Mode limits background work.	Keep working. Reduce heavy work if needed. Never reset the screen.
Headphones connect / disconnect	Audio switches between headphones and speaker.	Pause playback when headphones are removed. Don’t auto-play when they connect.
Siri / Google Assistant	Assistant UI and audio take over.	Pause audio like for a call.
Screen lock (power button or auto-lock)	Screen turns off. The app goes to the background.	Pause video. Keep timers correct. Restore the screen after unlock.
OS update or permission prompts	A system dialog appears on top.	Keep state. Continue after the dialog closes.
Another app’s audio	Music or a podcast is already playing.	Decide on purpose: pause the other audio, lower it (“ducking”), or mix with it.

What should happen

Whatever the interruption is, a well-behaved app does the same four things. Use them as your test oracle: if one fails, you’ve found a bug.

Pause what should pause. Video, music, games and voice guidance stop when a call, alarm or assistant takes over. They must never play under a phone call.
Save what the user typed. Form drafts, messages, unsaved edits and the current screen survive the interruption, even if the OS later kills the app in the background.
Keep time correct. Timers that measure real time (a workout, a parking meter, an OTP countdown) show the right value afterwards: no freezing, no jumping, no secretly restarting a timer the user paused.
Resume cleanly. After the interruption you’re back exactly where you left off, with nothing done twice. A payment, an order or a message is sent once, not again “because the app resumed”.

Try it: the interruption simulator

This phone runs three sample apps: a video player, a workout timer and a payment screen. Start something (play the video, let the workout run, tap Send) and then fire interruptions. The timeline shows what the system did and how a well-behaved app reacted. Check What you’d hear to spot audio clashes.

Interruption simulator

Pick a sample app, start something (play the video, run the workout, send a payment), then fire interruptions. The timeline shows what the system did and how a well-behaved app reacted.

StreamBox

1:1212:34

Sunset Yoga Flow

Episode 3 · Relax & stretch

Up next

Morning Energy · 9:12

Core Basics · 14:05

Fire an interruption

What you'd hear

Silence

Event timeline

Fire an interruption to see what happens…

what the system did how the app reacted

What to test

Group your interruption testing by what the user is doing when it hits. The most valuable moments are the ones where losing state hurts.

During media

Video or music playing → incoming call, alarm, Siri, headphones removed.
After the interruption: is it paused at the same position? Does it resume only when the user asks (or automatically, if that’s the spec)?
With Spotify already playing → start your app’s video. What happens to Spotify?

During input

Half-filled form (sign-up, address, chat message, review) → call, then decline; call, then accept and talk for a minute; lock screen.
Is every field still filled? Is the keyboard or focus in a sensible place?

During something that counts time

Workout, cooking timer, parking session, OTP code countdown, quiz with a time limit.
Lock the phone for 2 minutes, then unlock: does the timer show the real elapsed time? Is a paused timer still paused?

During a transaction

Payment, order placement, booking, file upload, sending a message.
Interrupt while the spinner is showing. Afterwards: one charge, one order, one message. The screen shows the final result, not an endless spinner. See double submit and idempotency.

During audio or video calls inside your app

If your app makes calls itself (WhatsApp-style VoIP, video consultation, ride-hailing driver calls), test a normal phone call arriving during them. Which call wins? Can the user switch?

Common bugs

#	Bug	What you see	Typical severity
1	Media plays under a call	Video audio continues while you’re talking on the phone	Medium
2	Form draft lost	Back from a call, the fields you typed are empty	Medium–High
3	Double transaction	Payment or order sent again after returning from a call or unlock	Critical
4	Timer wrong after interruption	Workout froze while locked, jumped after unlock, or a paused timer is running again	Medium–High
5	Audio blasts from the speaker	Headphones disconnect and the video keeps playing out loud	Medium
6	Auto-play on connect	Headphones connect and the app starts playing without being asked	Low–Medium
7	Blank screen or crash after unlock	White screen, frozen UI or a crash when you return	High–Critical
8	Endless spinner	A request finished while you were away, but the app never shows the result	High
9	Session expired during a short call	A 2-minute call logs you out and loses your progress	Medium
10	Banner breaks the layout	A notification banner shifts content or blocks a button permanently	Low

Find the bug

The same simulator again, but this time the app is broken. There are six bugs. Explore it like a tester:

Try each sample app with each interruption.
Start something first, then interrupt it.
Watch What you’d hear and the network log.
Some bugs need you to wait a little before coming back.

🐞 Bug hunt: Interruptions in a buggy app

This demo has 6 hidden bugs. Explore it like a tester, then check your findings.

Found0/6

StreamBox

1:1212:34

Sunset Yoga Flow

Episode 3 · Relax & stretch

Up next

Morning Energy · 9:12

Core Basics · 14:05

Fire an interruption

What you'd hear

Silence

Event timeline

Fire an interruption to see what happens…

1
Hint: Play the video, then fire an incoming call or an alarm. What would you hear?
Video keeps playing under the call
The app ignores the audio interruption: video audio keeps playing on top of the ringtone and the call, and the video position keeps moving. Expected: the video pauses as soon as the call or alarm starts, at the same position.
2
Hint: Open Workout, tap Pause, then take a call (or alarm) and come back.
A paused workout starts counting again after an interruption
When the interruption ends, the app calls "resume" no matter what. A workout the user paused on purpose is running again and adds time the user never trained. Expected: a paused workout stays paused; only a running one keeps running.
3
Hint: Open Payment with the amount and note filled in, then receive a call and decline it.
Payment draft is wiped after a call
Back in the app, the amount and note are empty. Expected: the draft is kept exactly as typed. This is a state persistence bug.
4
Hint: Tap Send and, while "Sending payment…" is showing, fire an incoming call. Watch the network log and the balance.
Payment is sent twice
On return the app re-submits the pending payment: the network log shows two POST /payments requests with different keys, the balance drops twice and Recent shows two payments. Expected: one request; on return the app shows the result of that same request. Severity: Critical (users lose money).
5
Hint: Play the video, then tap Unplug headphones.
Audio continues through the speaker when headphones are unplugged
"What you'd hear" switches to Video audio · phone speaker and playback continues. Expected: playback pauses when headphones are disconnected, so audio never blasts out loud in public. This is the platform convention on iOS and Android.
6
Hint: Lock the screen, wait about 10 seconds, then unlock.
Blank screen after unlocking
After the screen was locked for a while, unlocking shows a blank white screen and the app is unusable until it is restarted. Quick lock/unlock works, which is why this slips through. Expected: the app comes back exactly as it was, however long it was locked.

More tips on writing this kind of report: Writing bug reports.

Tools & how-to: triggering interruptions

You don’t need special hardware. A second phone and the built-in emulator tools cover almost everything.

The most realistic option, and the only one for some interruptions.

Calls: call your test phone from a second phone (or ask a colleague). Test ringing → decline, ringing → accept, talk 30 s, hang up, and missed (let it ring out). Also try a WhatsApp or FaceTime call, since VoIP apps use the same system call screen.
SMS and notifications: text yourself, or send a push from your team’s test tool or Firebase console.
Alarms and timers: open the Clock app, set a timer for 10 seconds, switch to your app and start the action you want to interrupt. For alarms, set one for the next minute.
Low battery: test on a phone below 20%, or turn on Low Power Mode (iOS: Settings › Battery) / Battery Saver (Android: Settings › Battery).
Headphones: pair Bluetooth earbuds, start playback, then take them out of your ears or put them back in the case. Also try turning Bluetooth off.
Siri / Assistant: hold the side button (iOS) or say “Hey Google” during playback.
Lock: press the power button, wait, unlock. Also let auto-lock kick in by not touching the phone.

Open the Extended controls with the ⋯ button on the emulator’s side toolbar.

Phone: enter any number and click Call device to simulate an incoming call (you can answer, decline and hang up from the emulator). Send message delivers a fake SMS.
Battery: set the charge level (for example 15%), unplug the charger and change the battery status.
Power button on the side toolbar locks and unlocks the screen.

The same with adb commands, handy for repeating a test:

adb emu gsm call 5551234          # incoming call
adb emu gsm cancel 5551234        # caller hangs up
adb emu sms send 5551234 "Hi!"    # incoming SMS
adb shell dumpsys battery unplug
adb shell dumpsys battery set level 15
adb shell dumpsys battery reset   # back to normal

The iOS simulator cannot receive real phone calls or SMS, and it has no real battery, Bluetooth or alarm sound. Use it for what it can do, and test the rest on a real device.

Lock: Device › Lock (⌘L). Home: Device › Home (⇧⌘H).
Siri: Device › Siri.
Push notifications: drag an .apns file onto the Simulator, or run xcrun simctl push booted com.example.app payload.apns.
Battery icon: xcrun simctl status_bar booted override --batteryLevel 15 only changes the icon (handy for screenshots). It does not trigger low-battery behavior.

Example test cases

TC-INT-001Video pauses on incoming call and stays paused after itpositivehigh

Preconditions

A video is playing at 1:20
Second phone available to call the test device

Steps

Call the test device from the second phone
Decline the call
Return to the app

Expected result

Video paused when the phone started ringing, at about 1:20. No video audio played during the ringtone. It resumes only when the user taps Play.

TC-INT-002Form draft survives an accepted callpositivehigh

Preconditions

Checkout address form is half filled

Steps

Receive a call and accept it
Talk for 60 seconds
Hang up and return to the app

Expected result

The same screen is shown and every field contains exactly what was typed.

TC-INT-003Payment is not duplicated when interrupted mid-requestedgehigh

Preconditions

Proxy tool records traffic
Balance €1,240.00

Steps

Enter €25.00 and tap Send
While the spinner shows, receive a call
Decline and return to the app

Test data

Amount: 25.00 EUR, recipient: Anna Lee

Expected result

Exactly one POST /payments. The app shows "Payment sent" once. Balance €1,215.00.

TC-INT-004Paused workout stays paused after an alarmedgemedium

Preconditions

Workout started and paused at 05:00
Timer in the Clock app set to 10 seconds

Steps

Wait for the timer to go off
Stop it
Return to the workout

Expected result

The workout still shows 05:00 and Paused.

TC-INT-005Playback pauses when Bluetooth headphones disconnectpositivemedium

Preconditions

Bluetooth earbuds connected
Video playing

Steps

Put the earbuds back in their case

Expected result

Playback pauses immediately. No audio comes from the phone speaker.

TC-INT-006App restores correctly after a long screen lockedgehigh

Steps

Open the order details screen
Lock the phone
Wait 10 minutes
Unlock

Expected result

The order details screen is shown and usable (no blank screen, no crash). Data is refreshed if it may have changed.

TC-INT-007Notification banner does not interrupt the appnegativelow

Preconditions

Video playing

Steps

Send an SMS to the test device
Let the banner disappear on its own

Expected result

Video keeps playing. No layout change, no lost input.

Tip: click a test case to expand it.

Checklist

Interruption test checklist

0 of 13 checked

Check your understanding

Quick quiz

0/5 answered · 0 correct

1.A video is playing and a call comes in. What should the app do?
2.Which interruption normally should NOT change anything in the app?
3.After returning from a call, you see two identical payments. Which concept protects against this on the server?
4.Your Bluetooth headphones disconnect while music plays. What is the expected behavior?
5.You need to test an incoming call. What is true about the iOS Simulator?

Key takeaways

Interruptions (calls, notifications, alarms, low battery, headphones, assistants, screen lock) happen to every user, every day. Test them on purpose.
A well-behaved app does four things: pause what should pause, save what the user typed, keep time correct, and resume cleanly without doing anything twice.
The most valuable moments to interrupt: during media, input, timers and transactions.
Use a second phone and the Clock app on real devices, Extended controls or adb emu on the Android Emulator. The iOS Simulator can’t do calls.
Interruptions often push the app to the background. Continue with Background and Foreground.