Permissions, interrupts, backgrounding and battery

A mobile app does not run alone and uninterrupted the way a desktop program on a big screen does. It asks for permissions (camera, location, notifications), it gets interrupted (a phone call, a notification, the screen locking), it gets backgrounded (the user switches apps and comes back), and the OS may kill it to save memory or battery. Each of these is a moment an app can break, and none happens in a quick happy-path demo. This lesson is testing the mobile lifecycle and its interruptions — the bugs that only appear when the phone behaves like a phone.

Permissions: the request, the denial, and the revocation

Mobile apps must ask for access to sensitive things — camera, location, contacts, notifications, storage — and the user can grant or deny, now or later. This is a rich source of bugs because there are several paths:

Granting — the happy path: the user allows, the feature works. Tested.
Denying — the user says no. Does the app handle it gracefully (a clear "we need the camera to scan a QR code; enable it in settings") or crash / show a blank screen / silently do nothing? Denial is the most under-tested permission path and where apps commonly break.
"Ask again" / "only this time" — modern OSes have nuanced options (allow once, while using, deny and don't ask). Each behaves differently on the next launch.
Revoking later — the user grants, uses the app, then revokes the permission in system settings and returns. Does the app notice and handle it, or assume it still has access and crash?
First-run vs subsequent — the permission dialog appears the first time; on later runs the app must behave correctly whether it was granted or denied before.

Test every path, not just "grant and it works": deny it, grant-then-revoke, allow-once-then-return. A QR scanner that works when you allow the camera but crashes when you deny it is a real, common, easily-missed bug.

Interruptions: the phone being a phone

While the app is in use, the phone interrupts it constantly, and the app must survive each:

An incoming phone call — mid-transaction. The app is backgrounded, then the call ends and it returns. Does it resume correctly, or lose state, or double-submit?
A notification — the user pulls down the shade, or taps a notification that switches apps.
The screen locking (timeout or the user pressing the button) mid-action, then unlocking.
A low-battery warning, an alarm, another app taking focus.
Rotation — the screen rotates (if allowed); does the layout survive and the state persist? A classic Android bug is losing the entered form data on rotation.

The test: do a critical action (say, a top-up) and interrupt it at each step — get a call, lock the screen, switch apps, rotate — then come back and check the app is in a sane state (not crashed, not lost the data, not silently duplicated the action). Interrupt-and-return is a whole category of test the happy path never touches.

Backgrounding, killing, and lifecycle

The deeper version of interruption is the app lifecycle: the OS moves your app between states, and can terminate it:

Backgrounding and returning — the user switches to another app and comes back minutes (or hours) later. Is the app where they left it, with their data, or reset? Does a half-finished transaction survive or vanish?
The OS killing the app — on a low-memory phone (the fragmentation lesson), the OS kills a backgrounded app to reclaim memory. When the user returns, the app is relaunched from scratch but the user expects to be where they were. Does it restore state, or dump them at the login screen having lost their in-progress top-up? This is a major, real bug on budget phones and is invisible on a flagship with plenty of RAM.
Process death mid-transaction — the worst case for a money app: the app is killed during a transaction. When relaunched, is the transaction safely resolved (completed or cleanly abandoned), or left in a broken half-state?

Testing this: background the app and force-kill it (developer options can simulate the OS killing a backgrounded app), then relaunch and check state — especially mid-transaction. On a low-RAM device, this happens to real users without them doing anything, so it is not an edge case; it is Tuesday.

Why this matters for the target apps

For mobile-first, money-handling apps on mostly budget devices, these lifecycle and interruption cases are where costly, hard-to-find bugs live:

Budget phones kill backgrounded apps aggressively (little RAM, plus manufacturer battery-savers), so "app killed and relaunched mid-flow" is common, not rare — and if a transaction is not handled safely across it, money or data is lost or duplicated.
A call or lock mid-transaction (people multitask, phones ring) can duplicate or lose a payment if the app resumes badly.
Permission denial breaks features silently for the cautious users who say no.

So a mobile QA deliberately interrupts, backgrounds, kills, and denies — especially during money flows, especially on a low-end device — because that is exactly the messy reality the app meets and the developer's uninterrupted demo on a flagship never showed. These join connectivity as the mobile-specific tests that find the expensive bugs.

Check your work

Permissions. Test every path, not just grant-and-works: deny (graceful message vs crash — the most under-tested), allow-once/while-using, grant-then-revoke-in-settings-and-return, and first-run vs subsequent launches.

Interruptions. The phone interrupts constantly — incoming call, notification, screen lock, alarm, focus loss, rotation — all mid-action; interrupt a critical flow at each step and check the app returns to a sane state (no crash, no lost data, no duplicate).

Lifecycle and killing. Background-and-return (state preserved?), the OS killing a low-memory backgrounded app and relaunching from scratch (does it restore, or dump the user at login having lost their in-progress action?), and process death mid-transaction (safely resolved or broken half-state?).

Why it matters for the target apps. Budget phones kill backgrounded apps aggressively (common, not rare); calls/locks mid-transaction can duplicate/lose payments; permission denial silently breaks features. Deliberately interrupt/background/kill/deny during money flows on a low-end device — the messy reality the demo never showed.

Practice

For a feature needing a permission (camera QR scan), test all paths: grant, deny (check the message not a crash), allow-once, grant-then-revoke-and-return.
Start a top-up and interrupt it at each step with a phone call, a screen lock, an app switch, and a rotation; check the app returns sane and does not duplicate or lose the action.
Background the app mid-flow, force-kill it (via developer options / the OS), relaunch, and check whether your in-progress state survives or you are dumped at login.
Reason about why "OS kills the app" is common on a budget phone and rare on a flagship, and what that means for where you test it.
Force process death during a transaction and check the transaction is safely resolved, not left in a half-state.
List, for a money app, the three interruption/lifecycle scenarios you would test hardest and why.

Official documentation

Android — Activity lifecycle and process death — Backgrounding, state saving, the OS killing the app.
Android — App permissions best practices — The permission paths to test.
Apple — Managing your app's life cycle — iOS backgrounding and interruptions.

Next: fresh installs, upgrades and data migration.