Freeze the release identity
Record package name, version code, version name, source commit, build environment and signing certificate fingerprint. Keep the AAB/APK, mapping file and native symbols together where applicable. Confirm that the artifact uses production endpoints and safe release logging.
Do not store private keys or passwords inside the checklist. Reference the controlled secret location and authorized owner instead.
Walk the review path
Use a fresh device or profile and the exact submitted build. Complete onboarding, authentication, the main task, permission denial and any paid or restricted flow using the supplied review instructions.
| Gate | Required evidence |
|---|---|
| Artifact | Correct target, signing and version |
| Product | Core task works after clean install and upgrade |
| Review access | Reusable credentials and clear instructions |
| Declarations | Data, ads, audience and privacy match behavior |
| Recovery | Monitoring owner and corrective-release procedure |
A test account with expired access can block review even when every screen worked for the developer.
Test operational failure states
Check offline startup, server timeout, interrupted upload, low storage and process recreation where relevant. Confirm error messages explain the next action without exposing secrets. Review accessibility with keyboard/switch or screen-reader paths appropriate to the platform.
For monetized apps, use official test ads or test purchases. Never create artificial live-ad clicks to prove monetization works.
Define the release stop conditions
Choose signals for crashes, ANRs, login failures and transaction errors. Decide who can halt expansion and who can build a correction. A percentage rollout is useful only when someone watches the results.
APKLint's release checklists can organize these gates and help inspect selected artifact properties. They do not run the device tests or guarantee review acceptance.
Consult app-review preparation, release management and Android signing. Mark each item with evidence and an owner rather than completing the checklist through optimism.
Rehearse the saved-data upgrade before launch
For an illustrative notes app, install the current production version and create a folder, a note with an attachment and an unfinished edit. Upgrade to the candidate without clearing application data. Confirm that the folder membership, attachment and edit recovery behave as promised. A clean-install smoke test cannot exercise the migration of records created by the previous version.
Repeat with synchronization temporarily unavailable. Record whether the app preserves pending changes and distinguishes local completion from remote confirmation. If the release introduces a new server representation, verify that the previous supported client still handles the relevant records while both versions are in use.
Give the launch owner an evidence handoff
Turn each unresolved observation into a decision with a named owner. For example, an attachment that reappears after deletion needs a synchronization repair and retest; changing the checklist status cannot resolve it. Associate the retest with the exact corrected version code so an earlier failed candidate is not promoted accidentally.
Practice retrieving the signed release and its matching diagnostic files from the retained archive. A crash during launch is a poor time to discover that mappings were overwritten by a later build. Verify that the authorized release operator can prepare a correction without depending on an unavailable developer's workstation.
Use a synthetic support ticket to test the handoff between customer support and engineering. The useful information is the affected version, device context, failed task and a safe correlation identifier. Do not ask a user to email passwords or their complete private document merely to establish that an upload failed.
Keep publication and service activation coordinated. If a remote feature must remain disabled until compatible clients are available, document that dependency and the observation that allows activation. Treat enabling it as an explicit release step, with a way to stop further exposure if the assumed compatibility fails.
The release-management guide explains Console's release controls. The rehearsal above supplies product-specific evidence for using those controls; it does not represent an automated device test or a promise of store approval.
Sources and further reading
- Google Play: Prepare your app for review
- Google Play: Prepare and roll out a release
- Android Developers: Sign your app
Reference review: 29 September 2026. Examples illustrate the workflow; check your installed versions, release artifact and account-specific Console requirements before applying them. This guide is not a claim that APKLint executed your project or verified your private account.
Android inspection tools and practical release guides. About APKLint · Report a correction
