Google Play Pre-Launch Report for Flutter Apps: A 5-Step Review Before You Publish (2026)
What does the Google Play pre-launch report check, and should a Flutter app fix everything in it?
The pre-launch report installs your app on a set of Android devices in Google's test lab, crawls it for several minutes by typing, tapping and swiping, and reports stability, Android compatibility, performance and accessibility issues. You do not have to clear every warning before you publish, but you should read the Stability section first, because crashes found there are the ones real users will hit. This guide gives the 5-step review I use for my own Flutter apps, and flags the one setting that decides whether the crawler sees past your sign-in screen.
Based on Google's Play Console Help pages, which I checked on 2026-11-06. Google can change how the report works, so check the Pre-launch report pages in your own Play Console.
The 5-step pre-launch review for a Flutter app
- Upload to a track and wait. Reports run automatically when you upload an app bundle or save a release to production, subject to capacity in Google's device lab. Google says you usually get results within an hour, sometimes several hours later, and that if the report is not complete after two days you can upload again to trigger a new one.
- Give the crawler a way in. If your app has a sign-in screen, add a test account under Pre-launch report settings, or use Sign in with Google, which the crawler can complete automatically.
- Read Stability first. Open Test and release, Testing, Pre-launch report, then the Details page. For each issue the Stability tab shows the number of devices affected and a stack trace, and a screenshot and video per device.
- Then Performance and Accessibility. Each Stability issue shows the device, Android version and a stack trace. Sort what you find into what hits common devices or core flows, and what can wait.
- Decide, then fix or ship. Fix what crashes. Log what you defer in your release notes so the next release starts with it.
The name is mine; the steps are the order I read Google's report in, and each point comes from the Help page linked below.
What does the report test?
Google's page lists four areas: stability issues, Android compatibility issues, performance issues and accessibility issues. After the crawl, the report gives a summary with the number of errors, warnings and minor issues by type, plus a launch recommendation based on the results. The report also uninstalls your app from all the test devices when it finishes.
| Level or area | What Google says it includes | What to do first |
|---|---|---|
| Errors | Crashes, ANRs, defective libraries and use of restricted unsupported APIs | Fix before you ship |
| Warnings | Slow startup and load times, sign-in or crawl issues, memory issues, unsupported APIs not yet restricted | Check sign-in and startup first |
| Minor issues | Missing content labels, colour contrast, small touch targets, implementation issues | Fix on key screens, log the rest |
| Performance tab | Per device: average CPU, network sent and received, memory (frames per second only for game loops) | Look for a CPU spike, then check what the crawler did at that moment |
| Screenshots tab | How the app looks across test devices and languages | Check that the crawler reached your main screens |
Treat the table as a reading order, not a pass mark. Google also says it cannot guarantee the tests find every issue, and that crashes found by the report come from test devices, so they do not affect your own crash statistics. Our Android vitals crash and ANR thresholds guide covers what counts as a problem once real users arrive.
The sign-in trap: will the crawler get past your login?
Google says you need to provide credentials if your app has a sign-in screen and you want the crawler to test sign-in or the content behind it. It adds that you do not need to if the app supports Sign in with Google, and that credentials can only be inserted into apps that use standard Android widgets. Credentials do not work in apps that render custom controls with OpenGL, or that use a WebView for a web-based sign-in flow.
Flutter draws its own widgets rather than using the standard Android ones, so I would not count on automatic credential entry. I have not confirmed how the crawler handles a Flutter login screen, so check your own report's Screenshots tab: if every screenshot shows the login screen, the crawler never got in. Google's advice for the account itself is to create a dedicated test account and not to put official credentials into the report.
How do you steer the crawler?
- Robo script. Record one in Android Studio with the Firebase Test Lab tool, then upload it in Pre-launch report settings. Google says the crawler runs your scripted actions first, then explores the app as usual.
- Deep links. You can add up to three. The crawler explores as usual, closes the app, then visits each deep link for a further 30 seconds. See our app links guide for setting them up.
- Languages. You can pick up to five languages for results. You can add them only after the first test has completed.
One more limit from the same page: the test devices are in the United States, so an app with geolocation or country restrictions can only show what is available in that location. And the report needs a main launch activity, so it cannot test launchers, widgets, keyboards or watch faces.
Obfuscated builds: upload your symbols
The report still runs on obfuscated code, but any crash it finds will have an obfuscated stack trace. Google recommends uploading a deobfuscation or symbolication file so the traces are readable. For a Flutter build with --obfuscate, our guide to uploading Crashlytics symbols covers the files to keep.
Where it fits in a release
The report is a safety net, not a replacement for your own testing. Run it after you upload to a closed or internal track, so the results are ready before you promote to production. Our Flutter Firebase release checklist has a place for it, and closed testing with 12 testers gives you real-device feedback the lab cannot. Review time is separate: see how long Google Play review takes.
I build and ship my own Flutter and Firebase apps under GSPTeck, giosaia's indie studio building mobile and web apps with Flutter and Firebase; you can see what I make on the GSPTeck site.
FAQ
Do I need to fix every warning in the pre-launch report before publishing?
No. Fix crashes and anything that blocks a core flow, then log the rest. The report gives a launch recommendation based on its results, but it is a guide, not an approval gate.
How long does a pre-launch report take?
Google says results usually arrive within an hour of upload, sometimes several hours later. If the report is not complete after two days, upload the artifact again to trigger a new one.
Why are all my pre-launch screenshots the login screen?
The crawler probably could not sign in. Add a test account in Pre-launch report settings or support Sign in with Google, and remember Google says credentials work only with standard Android widgets.
Can the pre-launch report test my app's country-specific features?
Only partly. Google's test devices are located in the United States, so geolocation and country restrictions show what is available there. A test build without the location requirement is Google's suggested workaround.
Sources
- Play Console Help: Use a pre-launch report to identify issues (checked 2026-11-06)
- Play Console Help: Understand your pre-launch report (checked 2026-11-06)