The pre-launch report is an automated test run that Google Play does on your build before you release it. It runs without extra setup on your side, so it is worth reading every time. It is also easy to over-read: it is a robot, not a user.
What it does
According to Google's Play Console Help, the report looks for stability, Android compatibility, performance and accessibility issues. It runs when you upload an app bundle or APK and when you save a release to production. The app is launched on devices in Google's test lab. A crawler then taps, types and swipes for several minutes. Afterwards the results are compiled.
Details from the same page that shape how you read it:
- Results usually arrive within an hour of the upload. If a report is not complete after two days, re-upload the build.
- Test devices run Android 9 and above, and include phones, tablets, Wear OS and desktop-class devices. Android Automotive OS and Android TV can't be tested.
- Devices are in the United States and run in portrait by default.
- You can add up to three deep links as extra entry points, test account credentials, a Robo script or a game loop, and choose up to five languages.
- Apps without a main launch activity can't be tested (Google names launchers, widgets, keyboards and watch faces).
The scope changes over time. Open the current page before you rely on any of this.
What it cannot see
The crawler does not know your product. It cannot judge whether onboarding makes sense, whether a price is clear, or whether text reads well. It may not get past a login unless you give it credentials. Anything behind a payment, a rare state, or a real-world action (a delivery, a Bluetooth device) is outside its reach.
How to triage findings
The report's overview groups issues as errors, warnings and minor issues and gives a launch recommendation. Use it as a starting point, not a verdict.
| Finding | What to do |
|---|---|
| Crash with a stack trace in your code | Reproduce it by hand. If you can, fix before release. |
| Crash in a third-party library | Check whether it affects a real flow; update the library if possible. |
| Crash only after the crawler did something unnatural | Lower priority, but check that the app handles odd input without data loss. |
| Accessibility warning (touch target, contrast, missing label) | Usually cheap to fix and valuable. Verify on your own device. |
| Performance warning | Compare with a real mid-range phone before you act. |
| Login wall, nothing tested | Add test credentials and run again. |
A simple rule: fix what you can reproduce, note what you can't, and ignore nothing without a reason written down.
Use it next to real testers
The report finds crashes and obvious defects on a fixed set of devices, quickly. People find confusing flows, wrong wording and problems on their own phones. Use both. For the field-data side, see Android vitals basics; for the comparison, see cloud device tests vs real testers.
Part of the Android app testing guide.
Need real people to try your build? Start here and get private, structured feedback.