AppReviewX Log in

Android release checklist: from build to rollout

A pre-release checklist covering build, signing, listing, testing and staged rollout.

updated ·3 min read

In this guide

A release goes wrong in boring ways: a debug flag left on, a wrong version code, a listing that doesn't match the app. This checklist covers the production step. If you are still in a closed test, use the closed testing checklist first.

Each item has a reason and a way to check it.

Build

  1. Release build, not debug. Debug builds are slower, larger and may expose logs or test servers. Check: build the release variant and confirm that debug menus, test endpoints and verbose logging are gone.
  2. Version code is higher than the last upload; version name is correct. Google Play does not accept an upload with a version code you have already used, and each release should use a greater value. Check: compare to your last release in Play Console.
  3. Dependencies and keys are production values. API keys, analytics IDs and server URLs often differ between test and production. Check: read the release config, not the debug one.
  4. Target API level meets the current requirement. Google raises it on a regular schedule, with deadlines for new apps and updates; read the current table on Google's target API level page before submitting. Check: compare your target SDK with that page.

Signing

  1. The upload key is safe and backed up. Losing it makes updates painful. Check: know where the keystore and its passwords are, and who has access.
  2. The artifact is signed as expected. A wrong key means an install conflict for testers or users. Check: install the exact release file on a clean phone.

Testing the exact artifact

  1. Install the release build on a clean device and run the main flow. The release build behaves differently from debug (minification, resource shrinking). Check: first start, sign-up, main action, a purchase if you have one, sign-out.
  2. Upgrade from the previous version. Data migrations break here. Check: install the old release, add data, update, confirm data survives.
  3. Read the pre-launch report. Google runs it when you upload and when you save a release to production. It covers stability, compatibility, performance and accessibility. Check: triage the findings; see how to read it.
  4. Run through offline and network changes. See network switching test.
  5. Check app size and a low-end phone if your audience includes one. See app size.

Listing

  1. Description, screenshots and the "what's new" text match this version. Mismatches cause bad reviews. Check: open the draft listing next to the running app.
  2. Data safety and privacy answers match what the app does. Google says you alone are responsible for accurate declarations and that they must stay accurate; inaccurate ones can lead to enforcement. Check: compare against your SDKs and permissions; no legal advice here, check Google's current forms.
  3. Contact email and privacy policy URL work. Check: click both.

Rollout

  1. Use a staged rollout for updates. Google's help page says staged rollouts apply to app updates, not to the first publication of an app. You choose a percentage; it doesn't grow by itself, you raise it in Manage rollout. Users are picked at random.
  2. Know how to halt. Halting stops the release from reaching more users; people who already have it keep it. To fix a problem, release a new fixed build.
  3. Watch crashes and feedback during the rollout. Check Android vitals and your tester channel before raising the percentage.
  4. Update the store listing after 100% if the listing changes depend on the release (the help page suggests this).

Part of the Android app testing guide.

Want a last round of real eyes before rollout? See how AppReviewX works: private, structured feedback.