On this page
Your users spend their time in elevators, tunnels, crowded venues, and trains, which means your app will eventually run with no usable connection. Apps tested only on a fast office network fail in exactly those moments: a frozen spinner, a lost form entry, a crash on a timeout. This guide covers the network states worth testing on Android and how to reproduce each one on demand.
The states worth testing
- No connection at launch: the app opens cold with the device fully offline.
- Connection lost mid-action: the network drops during a payment, upload, or form submission.
- Slow and high-latency network: pages load, but slowly enough to expose missing progress states.
- Connection returns: the app recovers without a restart or duplicate submissions.
- Captive portal: Wi-Fi that requires a login page before traffic actually flows.
- Network switch: the device moves from Wi-Fi to cellular or back in the middle of a session.
- Data Saver enabled: background sync and heavy transfers behave differently when the user limits data.
How to reproduce each state
Cut connectivity with airplane mode
The fastest way to a true offline state, on a device or emulator. Toggle it on before launching the app to test the cold offline path, and toggle it mid-flow to test interruption.
Throttle with emulator network profiles
The emulator's extended controls let you set connection speed and latency profiles that approximate older mobile networks. Use them for the slow network case, where timeouts and loading states become visible.
Flip networks by hand
Switch Wi-Fi off while connected to cellular, or move between two networks. Watch what happens to a request in flight and whether queued work resumes once the new connection is up.
Test with Data Saver on
Enable Data Saver in system settings and repeat flows that sync in the background. Apps that ignore metered-connection restrictions behave differently here than on an unrestricted device.
What the app should do in every case
- Never hang silently: show a loading state, then an offline message the user can act on.
- Keep what was already loaded readable instead of blanking the screen.
- Preserve user input so a dropped connection does not erase a typed form.
- Retry intelligently: bounded retries with backoff, not a request storm.
- Fail without crashing: an unreachable host is a normal condition, not an exception the user should meet.
- Recover on its own when connectivity returns, without forcing a restart.
Want the whole network matrix run for you?
AppsTestLab tests Android apps across offline, throttled, and interrupted network states as part of a functional test pass, and reports every state that fails with reproduction steps.
Request network testingFrequently asked questions
Frequently asked questions
Is airplane mode enough to test offline behavior?
It covers the clean offline case, which is the easiest one. The harder failures happen on poor or interrupted connections, where requests half-succeed, so throttle and network-switch tests matter just as much.
Should offline behavior be automated?
The states are scriptable, especially in emulator runs with network profiles, so the critical offline checks belong in your regression suite. Keep a manual pass too for judging what the offline screens actually say and feel like.
Sources
Sources & references
Official Google documentationThese links open Google's official Play Console Help pages used to verify this guide. AppsTestLab guidance is independent and not affiliated with Google.
Get help doing this