The pre-launch report is an automated test Google Play runs on your app when you upload an app bundle or APK. A crawler opens your app on test devices, taps and swipes through it, and reports crashes, compatibility problems, performance issues and accessibility warnings. It is free, it runs without you asking, and it often catches problems your human testers never hit.
What the pre-launch report does
According to Google's pre-launch report help page, the report is "automatically generated when you upload an app bundle or APK," and also when you save a production release.
- A crawler runs your app on devices in Google's test lab.
- It types, taps and swipes to explore screens.
- It checks stability, Android compatibility, performance and accessibility.
- Results usually arrive within an hour, though sometimes it takes several hours.
- There is no charge.
Google does not publish a fixed number or list of devices used, so do not plan around a specific count. Look at the device list in your own report instead.
Why it matters during closed testing
Your closed testers use real devices, which is the point of the requirement. But 12 people cannot cover every Android version, screen size and manufacturer. The pre-launch report adds automated coverage on top.
It also helps with the question Google asks when you apply for production access: how you decided the app was ready. Google wants apps that are "stable and free from broken functionality, crashes, or missing screens." A clean pre-launch report, plus the fixes you made from it, is good evidence. Our article on what Google looks at in production access explains the form in more detail.
How to read the report
Open the pre-launch report for the build you uploaded in Play Console. It is organized into a few areas.
Overview
A summary of issues by category and the devices tested. Start here to see whether anything is marked as serious.
Stability
Crashes and ANRs (app not responding) found by the crawler, with:
- the device and Android version
- a stack trace
- often a screenshot or video of the steps that led to the crash
Treat every crash here as real until you prove otherwise. If it happens on a device model your testers did not have, it will happen to users too.
Performance
Performance information the crawler collected on the test devices. Use it to spot obvious regressions between builds rather than as absolute scores.
Accessibility
Warnings such as small touch targets, low color contrast, or images without content labels. These do not usually block anything, but fixing them makes the app usable for more people and often improves the design for everyone.
Screenshots
Images of the screens the crawler reached on different devices. Scroll through them to spot layout problems: text cut off, buttons off screen, broken layouts on small or large displays.
When the crawler gets stuck at login
If your app opens on a login screen, the crawler may not get past it, so most of the app goes untested. Play Console lets you provide test credentials in the pre-launch report settings, so the crawler can try to sign in. Use a dedicated test account, never a real user's account.
This is separate from the sign-in details you give app reviewers under Policy and programs > App content. Both should work. Our article on giving testers and reviewers login access covers the reviewer side.
A routine that works
- Upload a new build to your closed track.
- Wait for the pre-launch report (usually within an hour).
- Fix any crashes first, then ANRs.
- Note accessibility warnings and fix the quick ones.
- Ship the fixed build to your closed track, and check the next report.
- Keep a short log of what you fixed. You can use it when you describe your testing in the production access form.
What the report cannot do
- It does not replace human testers. It cannot judge whether a feature makes sense or whether your onboarding is confusing.
- It does not count toward the 12-tester requirement. Only real testers opted in to your closed test count.
- It cannot reach screens behind steps it does not understand, such as payments or hardware features.
Key takeaways
- The report runs automatically on every upload and costs nothing.
- Check stability first, then screenshots for layout problems, then accessibility.
- Give it test credentials if your app requires sign-in.
- Use the fixes as evidence of readiness when you apply for production.
Your human testers and the pre-launch report work best together. If you need 12+ real testers for the 14-day closed test, see our guide or order a test with GoPlayTester. Google makes the final decision on production access.
