The crawler cannot log in on the web
Google states that test-account credentials cannot be used when an app signs users in through a web-based flow inside a WebView. Behind a login screen, the crawler sees one page on every device.
What the pre-launch report does
When you upload an app bundle to Play Console, Google automatically installs it on a selection of devices in its test lab (phones, tablets and sometimes Chromebooks, running Android 9 or newer), lets a crawler explore it for several minutes by tapping, typing and swiping, and then uninstalls it. Results are usually ready within about an hour, sometimes after several hours. If a report has not finished after two days, a new upload starts a fresh one.
The report counts errors, warnings and minor issues, groups them into stability, performance, accessibility and security findings, and adds screenshots and videos per device. It is a diagnostic tool, not a review verdict: a warning does not stop you from rolling out. But on first launch the crawler and a human reviewer see your app the same way, so anything that blocks the crawler probably blocks the reviewer too. For the causes of crashes and white screens, see the broken functionality guide; this page is about reading the report.
Why a WebView app looks noisier than it is
Web content is audited as app UI
Accessibility checks read what the WebView exposes, so an icon button without a label in your React code becomes a finding for your app.
SDKs bring their own findings
Warnings about non-SDK interfaces or library versions often come from ad, push or analytics SDKs, not from anything you wrote.
Every run is a fresh install
No cookies, no stored consent, no session. A cookie banner or an onboarding modal appears on every device and covers what you wanted the crawler to see.
Finding by finding: what it means and what to do
| Finding | Usual meaning in a WebView app | Priority |
|---|---|---|
| Crash or ANR | A feature switched on without its configuration, for example ads without an AdMob app ID or Firebase push without google-services.json | Fix before release. The stack trace usually names the SDK |
| Blank or white screenshots | The URL was unreachable, bot protection blocked the test-lab traffic, or mixed content stopped the page | Fix before release. A reviewer would see the same |
| Screenshots show only the login page | The crawler could not sign in through the web login | Fix for review readiness: a public or demo area plus deep links, see below |
| Cookie banner on every screenshot | A consent overlay shown on the first visit | Make it compact so the content stays visible; keep any consent prompt you are legally required to show |
| Security warning about SSL handling | The WebView is allowed to continue on certificate errors | Fix. Set BLOCK_SELF_SIGNED_AND_FAULTY_SSL_CERTS to true and repair the certificate chain at your host |
| Security warning about a library version | An old SDK version from an outdated template | Fix by building from the current WebViewGold template |
| Accessibility: touch target size | Links and icon buttons in your web app smaller than about 48 x 48 dp | Fix main navigation and primary buttons; small inline text links can wait |
| Accessibility: content labels | Icon-only buttons and images without an accessible name | Fix in the web app with aria-label and alt text |
| Accessibility: low contrast | Light gray text, placeholder text, pale buttons | Fix where it affects body text and primary actions |
| Performance: slow start or janky frames | A heavy JavaScript bundle or large images on the start page | Improve when you can; not a blocker |
| Non-SDK interface usage | Hidden Android APIs called by an SDK | Usually informational; keep the template and its SDKs current |
I am very happy I bought this app! Extremely easy and great documentation. Was in contact with the customer service, they replied very quickly and very friendly. They solved my question within a day. 10/10 would recommend.
Make the crawler see your real app
These changes help the crawler, the reviewer and your store screenshots at the same time.
Give the first screen something to explore
If your product allows it, open the app to a public area: a demo mode, a product tour or browsable content without an account. The crawler taps through what it finds; a lone login form gives it nothing to do.
Add up to three deep links
In the pre-launch report settings you can list up to three deep links. After the main crawl, the crawler opens each one and explores it for about 30 seconds; each link must match an intent filter in your app. With WebViewGold, enable the custom scheme (
IS_CUSTOM_SCHEME_ENABLEDandCUSTOM_DEEPLINK_SCHEME) or verified App Links as described in the App Links docs, then use links such asyourscheme://https://www.example.com/demoto send the crawler to public pages.Keep the demo account for humans
The credentials field in the report settings does not help with a web login in a WebView. Keep a working demo account under App access anyway, because human reviewers use it.
Make consent and onboarding compact
Every test device starts fresh. Keep the consent prompt small enough that the page stays visible behind it, and skip multi-step onboarding modals inside the app.
Upload, wait, read the details
Upload to internal testing with a new version code. Open the report, use View details on each finding and watch the device videos: they show exactly where the crawler got stuck.
Fix the web side first
Accessibility and performance findings are mostly fixed in your web app and go live without a new build. Native findings (crashes, SDK and security warnings) need a rebuild and a new upload.
Quick accessibility fixes for the app only
WebViewGold applies the project's custom.css to every page loaded in the app. That makes it a fast place for touch-target fixes while you correct the web app properly. Labels belong in the web app itself, for example aria-label="Open menu" on an icon button.
css
/* custom.css in the WebViewGold Android project: app-only tweaks */
/* Minimum touch targets for navigation and primary actions */
nav a,
button,
[role="button"],
.icon-button {
min-height: 48px;
min-width: 48px;
}
/* Keep the consent banner compact so the content stays visible */
.cookie-banner {
max-height: 30vh;
overflow: auto;
}Before you promote a build to production
- No crashes or ANRs in the stability findings on any device.
- Screenshots show real content on every device, not a white screen, a login form or a cookie banner.
- Security findings resolved; certificate errors are blocked, not ignored.
- Main navigation and primary buttons meet the 48 dp touch target, and icon buttons have labels.
- Up to three deep links cover your most important public screens.
- A working demo account is stored under App access for human reviewers.
- Web-side issues checked with the Play Store readiness check before the next upload.
Frequently asked questions
Does a warning in the pre-launch report block my release?
No. Findings are diagnostic and do not stop a rollout. Fix crashes, blank screens and security findings anyway, because a reviewer can run into the same problems.
Why is there no pre-launch report for my upload?
Reports depend on test lab capacity and usually take up to an hour, sometimes several. If nothing has appeared after two days, upload the bundle again with a new version code to start a new report.
Can I give the pre-launch crawler my login?
Not for a web login. Google states that test-account credentials cannot be used when the app signs users in through a web-based flow inside a WebView, which is the normal case for a wrapped app. Offer a public or demo area and add deep links instead.
Are accessibility warnings from my web app worth fixing?
The important ones, yes. Labels on icon buttons, readable contrast and large enough tap targets help real users and make the app feel native. They are fixed in your web code and go live without a new build.
The report lists non-SDK interface warnings. Should I worry?
Usually not. They mostly come from SDKs that use hidden Android APIs and are informational. Keeping the WebViewGold template and its SDKs current is the right response; you do not need to patch libraries yourself.
Why do the report screenshots look different from my phone?
The test devices cover other screen sizes and Android versions and always start with a fresh profile. A layout that breaks on a small phone or a tablet in the report is a real problem; fix it in your CSS.
Three ways to get your app into the stores
Same result, different amount of work on your side. All three come with the approval guarantee and 24/7 human support.
Do it yourself
$109 per platform, one-time
The WebViewGold license: a finished Xcode or Android Studio project. Paste your URL, set name and icon, switch on features, build and submit. Free updates forever.
See plans on the main pageCloud Builder
$349 per license, one-time add-on
No Mac, no Xcode, no Android Studio: configure in the browser, we build both apps in the cloud and hand them to App Store Connect and the Play Console.
How the Cloud Builder works Try the free demoFull Service
$698 per platform $798
Send us your URL and icon. Our team configures, builds and delivers your app within 72 hours, white-label, with source projects. Both platforms for $1,158.
Full Service details Powered by
Winter Sale prices valid until December 31, 2026.