Android release QA
Android QA Checklist Before a Google Play Store Launch
A release-candidate QA checklist for Android installation, core journeys, lifecycle, device layouts, performance, permissions, privacy, payments, accessibility, and recovery.
A Play launch checklist should test the actual production candidate, not only a debug build. Start with failure that can harm users—data loss, broken access, payment errors, privacy, and crashes—then verify usability and presentation across the devices your audience uses.
1. Release and installation
- Production bundle uses the intended application ID, signing key, version code, and version name
- No debug libraries, test endpoints, development menus, or secrets are included
- Clean install, update from the last public build, uninstall, and reinstall behave as intended
- Supported devices can find, download, install, launch, update, and remove the app
- Deep links, app links, notifications, shortcuts, and shared content open the correct destination
2. Core journeys and state
- New and returning users can complete the primary outcome
- Sign-up, sign-in, verification, logout, recovery, and account deletion are tested where applicable
- Empty, loading, partial, error, offline, and retry states explain the next action
- Back navigation, app switching, sleep, lock, rotation, process recreation, and resume preserve safe state
- Duplicate taps, retries, and reconnection do not create duplicate payments or records
3. Devices, layouts, and accessibility
- Representative small, standard, large, and tablet layouts are usable
- Latest Android and versions important to the audience retain core functionality
- Light, dark, increased font size, display scaling, and long translated text do not hide actions
- TalkBack labels, focus order, touch targets, contrast, and keyboard input support critical journeys
- Camera, location, biometrics, NFC, Bluetooth, storage, and other hardware degrade gracefully when unavailable
4. Performance and stability
Android's current core-quality guidance calls for responsive startup feedback, smooth rendering, no crashes or ANRs, latest-platform compatibility, current SDKs, and maintained third-party dependencies. Use the Play pre-launch report, Android vitals, profiler output, and real-device observation as complementary signals.
- Cold and warm startup are measured on a representative lower-capability device
- Scrolling, animation, media, and high-traffic screens avoid sustained visible jank
- Long tasks do not block the UI or produce an Application Not Responding event
- Memory, storage, network, background work, battery, and thermal behaviour are proportionate
- Crashes, ANRs, and high-severity pre-launch findings are resolved or explicitly accepted
5. Privacy, security, permissions, and policy
- Every permission is necessary, requested in context, explained, and safe when denied or revoked
- Sensitive data is encrypted in transit and excluded from logs, screenshots, analytics, and crash reports
- Privacy policy, consent flows, Data safety answers, and actual app behaviour agree
- WebViews, exported components, deep links, backups, clipboard, and local storage are reviewed
- Account deletion and data-retention controls work where required
- Target SDK, restricted permissions, content declarations, ads, and store listing satisfy current Play requirements
6. Release decision and monitoring
Create a final report with candidate build, environments, passed and failed critical journeys, unresolved risk, owner, and launch decision. Define the post-release signals and rollback or mitigation path before publishing. A staged rollout can reduce exposure, but it does not make a known unsafe build acceptable.