BenchFleet

Appearance

Published

Mobile app testing checklist for real Android phones ​

In short: Test on a few real phones that match your users, then go through installs and updates, first run, permissions, poor and changing networks, interruptions, screen settings, languages, accessibility, performance and security. This checklist gives each check with the adb command that sets it up. BenchFleet runs the same checks on every phone at once from one screen.

Most bugs that reach users come from conditions a developer's own phone never sees: an older Android version, larger text, no signal in a lift, a call in the middle of checkout. This checklist covers those conditions in the order a tester meets them, with the adb command that sets each one up, so the checks are quick to repeat on every build. Replace com.example.app with your app's package name.

Free for up to 3 phones, with no account. Pro adds workflows, schedules and AI for up to 25 phones from £12 a month + VAT.

Download freeSee pricing

1. Choose the phones ​

  • Android versions: the oldest version you support, the newest, and the one most of your users have.
  • Screen sizes: a small phone, a large one and, if your users have them, a foldable or a tablet.
  • Makers: at least two, since makers change settings, permissions dialogs and battery behaviour.
  • One low-end phone: little memory and a slow processor show performance problems first.
  • Real conditions: a real SIM card, your own Wi-Fi, and test accounts that look like real ones.

List what each phone is with adb devices -l, and the Android version with adb shell getprop ro.build.version.release.

2. Install, update and remove ​

  • Fresh install from the build you will ship, not a debug build only.
  • Update over the previous version with data in it: adb install -r app.apk keeps the data; check sign-in, saved items and settings survive.
  • Clear data and start again: adb shell pm clear com.example.app.
  • Uninstall and reinstall: adb uninstall com.example.app; check what your backup restores.

With several phones, the adb install guide has a loop for every phone in bash and PowerShell.

3. First run ​

  • Onboarding can be skipped, finished and resumed after the app is closed halfway.
  • Sign-up and sign-in work with a slow network, a wrong password and a locked account.
  • The app works, or explains why not, before the user grants any permission.

4. Permissions ​

  • Deny each permission at the prompt, then use the feature that needs it.
  • Revoke a permission while the app is open: adb shell pm revoke com.example.app android.permission.CAMERA.
  • On Android 13 and newer, deny notifications: adb shell pm revoke com.example.app android.permission.POST_NOTIFICATIONS.
  • Grant it back to continue: adb shell pm grant com.example.app android.permission.CAMERA.

5. Networks ​

  • No connection at all, then the connection coming back in the middle of a request.
  • Switching from Wi-Fi to mobile data during an upload or a payment.
  • A slow or captive network, such as a hotel's sign-in page.
bash
adb shell svc wifi disable
adb shell svc data disable
adb shell svc wifi enable
adb shell svc data enable

These work from adb's shell on most phones; where a maker blocks them, use the quick settings by hand.

6. Interruptions and the app's lifecycle ​

  • An incoming call, an alarm and a notification during the main flow.
  • Home, then back to the app after a few minutes; the screen locking and unlocking.
  • Android ending the app in the background: adb shell am kill com.example.app while it is in the background, then return to it. Check that the screen, the form contents and the scroll position come back.
  • Activities ending as soon as you leave them, as on a phone short of memory: adb shell settings put global always_finish_activities 1 (reset with 0).
  • Doze and battery saving: adb shell dumpsys battery unplug, then adb shell dumpsys deviceidle force-idle; check that scheduled work and notifications still arrive (reset with adb shell dumpsys battery reset).

7. Screen settings ​

bash
adb shell settings put system font_scale 1.3
adb shell wm density 600
adb shell cmd uimode night yes
adb shell settings put system accelerometer_rotation 0
adb shell settings put system user_rotation 1
  • Large text (font_scale): nothing cut off or overlapping. Reset with font_scale 1.0.
  • Display size (wm density): layouts still fit. Reset with adb shell wm density reset.
  • Dark mode (cmd uimode night, Android 10 and newer): every screen readable. Reset with night no.
  • Rotation (user_rotation 1 is landscape with auto-rotate off): state kept after rotating. Reset with accelerometer_rotation 1.
  • Split screen and foldables: the app resizes without losing state.

8. Languages and regions ​

  • A language with long words and one written right to left.
  • Dates, times, numbers and currencies in the phone's region.
  • Text the app receives from users, such as names with accents and emoji.

9. Accessibility ​

  • Every screen works with TalkBack: labels on buttons and images, a sensible reading order.
  • Touch targets are large enough and text has enough contrast.
  • Nothing depends on colour alone.

10. Performance ​

  • Cold start time: adb shell am start -W -n com.example.app/.MainActivity prints TotalTime in milliseconds.
  • Memory: adb shell dumpsys meminfo com.example.app after a long session.
  • Smoothness: scroll the longest list on the low-end phone.
  • Battery and heat: a long session on mobile data; the phone should not get hot doing nothing.

11. Security and privacy ​

  • Screens with passwords or payment details are left out of screenshots if your app marks them secure: why screenshots are black shows how to check.
  • Nothing secret in the log: adb logcat -d | grep -i "token\|password" should find nothing of yours.
  • Signing out removes the account's data from the phone.

12. Crashes and logs ​

  • After each run, check for crashes: adb logcat -b crash -d.
  • For a frozen screen, look for ANR in the main log, or collect everything with adb bugreport.
  • Attach the screenshot and the log to the bug report: adb logcat and adb screenshot cover both.

Where BenchFleet helps ​

Every check above can be done by hand on one phone. BenchFleet is for doing them on many phones, and for keeping the results:

  • Every phone on one screen, live, with its battery, temperature and connection, and one click to take control: the quickest way through sections 3, 7 and 9 on several phones at once.
  • Each phone's tools on its page: logcat with filters, an APK installer and a terminal for the commands above. See logcat, APKs and a shell on many phones.
  • The same build on every phone Pro: group actions install an APK on a group at once; a canary group can get it first.
  • Recorded checks Pro: record sign-in or the main flow once and run it on every phone after each build, on a schedule or from CI, with a screenshot of every step to compare layouts and a replay of every failed run.
  • Exploratory testing with AI Pro: an AI task explores a build with your own model, stays in the apps you allow and hands the phone to a person at sign-in checks and CAPTCHAs.

The same phones serve more than testing: AI agents such as Claude Code or Codex can use them over MCP with approvals, and support desks can take one over in a click. Watching and controlling phones is free for 3 phones; Pro is £12 a month + VAT for up to 25. More in Android app testing on real phones and managing a bench of Android test devices.

Questions ​

What should a mobile app testing checklist include?

The phones you test on, installs and updates, the first run, permissions, networks, interruptions such as calls and the app going to the background, screen settings such as rotation, dark mode and large text, languages, accessibility, performance, security and the crash log.

How many phones do I need for mobile app testing?

Enough to cover what your users have, not every model. Pick by Android version, screen size and maker, include one low-end phone, and add more when your users' data shows a gap. A cloud fills in models you do not own.

Can I run this checklist on many phones at once?

The setup commands loop over adb devices, and BenchFleet shows every phone on one screen. On Pro it installs a build on a group, runs recorded checks on every phone and keeps a screenshot of every step.

Should I automate the whole checklist?

Automate the checks you repeat on every build, such as sign-in, the main flow and settings, and keep a person on what needs judgement, such as layout, wording, accessibility and anything new.

How do I reset a phone between test runs?

Clear the app's data with adb shell pm clear and the package name, reset the settings you changed, such as font scale and display density, and turn the networks back on. Each section of this checklist ends with its reset command.

Start with the Free plan

Free for up to 3 phones, with no account. Pro adds workflows, schedules and AI for up to 25 phones from £12 a month + VAT.

Download freeSee pricing