How to Test an Android App Before Release

What should you test before an Android release?

Test the core job first, then the situations that break it. For an Android app that means five things: the main user journey, a weak or missing network, a range of phones, interruptions such as calls and low battery, and what happens when a user denies a permission. Most release-day bugs come from conditions the team never tried, not from the happy path.

This guide is the testing pass we run before we hand over a build. Use it as a checklist, and adapt it to your app.

Does the core journey work from a clean install?

Test as a new user, not as a developer with a signed-in account and saved data.

Install on a device that has never had the app. Check the first launch, onboarding and the first time the app asks for anything.
Complete the main job end to end. If the app is for logging expenses, add one, edit it, delete it and see the total change.
Check the empty states. A new user sees screens with no data before they see screens with data. Each one should explain what to do next.
Test sign-up, sign-in and sign-out. Include a wrong password, a forgotten password and signing in on a second device.

What happens on a slow or missing network?

Many users are on mobile data with an unstable signal. Test for it on purpose.

Turn on airplane mode in the middle of an action. The app should show a clear message and keep the user's input, not freeze or lose it.
Throttle the connection. Android's developer tools and many emulators let you simulate a slow network. Watch for screens that show nothing while loading.
Test a request that fails. A server error should produce a message the user understands and a way to try again.
Check what works offline. Decide which parts of the app should work without a connection, then test that they do.

Which phones should you test on?

You cannot test every Android phone, so choose a spread.

Include an older version of Android that your app supports, and the newest version.
Include a low-memory phone. Apps that run well on a flagship can be slow or close unexpectedly on an entry-level device.
Include a small screen and a large one. Check that text is not cut off and buttons stay reachable.
Test with larger system font size and with dark mode on. Both are common user settings and both often break layouts.

Emulators are useful for covering many screen sizes quickly. Real devices are needed for performance, the camera, notifications and anything that depends on hardware.

Do permissions and interruptions behave correctly?

Deny each permission once. The app should still work for everything that does not need it, and explain how to enable it later if the user changes their mind.
Receive a phone call while using the app, then return to it. Do the same with a notification, a switch to another app, and rotating the screen.
Run the app with low battery saver turned on. Background work may be delayed.
Kill the app and reopen it. Check that it restores to a sensible state.

What should be checked before you upload the build?

Install the release build, not the debug build. Release builds are signed and optimised differently, and some bugs appear only in them.
Confirm crash reporting is switched on so that you can see problems in the first hours after launch.
Check the version number and the target API level. Google's target API level requirement changes over time, so confirm the current rule before you upload.
Run the Google Play pre-launch checks in Play Console, if you use them, and read the results.

When these pass, move to the store requirements. Our Google Play release checklist covers the account, privacy policy, Data safety form and rollout.

How does testing fit with the rest of the build?

Testing works best when it happens during the build, not only at the end. In our process you receive a build every two weeks, so problems show up while they are still cheap to fix. If you are still deciding what the first release should contain, start with how to scope an app MVP. For general software quality practice beyond mobile, the main ThynkBlox blog covers software testing and quality assurance.

Want an installable build in your hands every two weeks? Our build service ends every sprint with a build you install on your own phone. Questions about ownership and timelines are in our FAQ.