How to read the Play Console pre-launch report

The pre-launch report is one of the more useful things in Play Console, and one of the easiest to ignore. It runs your app on real devices in Google's test lab and gives you a report before you release to production.

It is not a substitute for human testers. It is a second pair of eyes that never gets tired, and it can catch problems that your own phone will not.

What the report covers

The exact sections can change, but the report typically includes:

• Crashes and ANRs on a range of devices and Android versions.
• Performance signals such as startup time, frame rendering, and memory use.
• Accessibility findings, including missing content descriptions and small touch targets.
• Privacy and security warnings, such as insecure network traffic or risky permissions.
• SDK and dependency issues, including outdated or flagged libraries.
• Screenshots from the automated run, which can reveal layout problems.

It is generated from a build you upload to a testing track. You usually need to wait for the lab to run before the report is populated.

What it cannot tell you

The report does not know what your app is supposed to do. It can tell you that a screen crashed; it cannot tell you that the onboarding copy is confusing or that the pricing page is wrong.

It also may not reach flows behind a login, a paywall, or a complex setup. If the automated test cannot get past the first screen, the report will be shallow.

Treat it as a safety net, not a replacement for the closed test.

Which findings to fix first

Start with the things that would block a real user:

1. Crashes and ANRs. A crash on a common device is a launch blocker.
2. Security warnings. Insecure HTTP, exported components, or risky permissions can become policy problems.
3. Broken layouts. Look at the screenshots on small and large screens.
4. Accessibility issues. Missing labels and tiny touch targets are worth fixing before launch.
5. Outdated SDKs. A deprecated library may be a future policy or compatibility problem.

Not every warning is urgent. A minor performance note on an old device may be acceptable for a first release. Use judgment and fix the issues that affect real users or review.

A simple workflow

1. Upload the release to an internal or closed track.
2. Wait for the pre-launch report to run.
3. Open the report and read the summary first.
4. Triage crashes and security issues before cosmetic warnings.
5. Fix the important issues in a new build.
6. Re-run the report on the new build if you have time.
7. Mention the fixes in your production-access notes if they came from testing.

What to do with accessibility warnings

Accessibility findings are often easy wins:

• add content descriptions to icon-only buttons;
• increase touch targets to a comfortable size;
• check contrast on text and buttons;
• make sure form fields have labels;
• test with a screen reader if you can.

These changes help real users and can reduce review friction. They are also a good use of the middle of your 14-day window.

What to do with security warnings

Do not ignore a warning just because the app is small. Common issues include:

• cleartext HTTP traffic;
• exported activities or services that do not need to be public;
• excessive permissions;
• outdated libraries with known issues.

Fix the cause, not the warning. Removing a permission from the manifest without changing the feature can break the app; changing the feature so it no longer needs the permission is the better fix.

The short version

• The pre-launch report runs your app on real devices automatically.
• It is good at crashes, ANRs, accessibility, and security signals.
• It cannot judge your product, copy, or business logic.
• Fix crashes and security issues first.
• Use it alongside real testers, not instead of them.

Next: why Play Console shows zero testers, or the Google Play publishing checklist.