Google Play App Access: Test Credentials for Reviewers

Short answer: hand Google a working login before the app goes to review

If any part of your app sits behind a login, a subscription, a membership or a location check, Google wants a working way in before it reviews the app. That setting lives on App content in Play Console, in a section the help centre now calls Sign-in details and that older guides, developers and Google's own pre-launch report article still link to as App access. Google's Play Console Requirements make it a pre-submission item: you must “Provide an active demo account, login information, and all other resources needed for Google Play to review your app.” Skip it and Google states the consequence directly: “Otherwise, we won’t be able to review your app, and your app may be rejected.” This covers where the form is, what Google demands of the credentials themselves, why the pre-launch report is a separate and usually optional field, and how the same gap reaches your production access application.

What is App access, and why does Google require it?

Sign-in details (App access) is a questionnaire on your app's App content page. Google's instruction leaves no room for interpretation: “If your entire app or parts of your app are restricted based on login credentials, sign in details, memberships, location, or other forms of authentication, you must provide all required details to enable access to your app” (Prepare your app for review). The Play Console Requirements list it as item 3.3 of what you must do before submitting: provide “an active demo account, login information, and all other resources needed for Google Play to review your app (specifically, sign in details, QR code, etc.)” (requirements).

The label is unstable across Google's own pages, which is why this section confuses people. The help article heads it Sign-in details today. Google's pre-launch report documentation still links to that same article with an #app_access anchor, and Google's pinned community guidance calls it “the App access feature.” Same form, three names — search any of them and you land in the same place.

Plenty of apps get asked for credentials even though the front door is open. Google's Play Product Support team answered that in a pinned announcement: developers wonder why credentials are needed “when their app is not restricted by a login,” and Google's reply begins: “In many of these cases, the reason is that a specific area or functionality of the app is restricted by a login or subscription” (Login Credentials requirements tips). A paywall behind an otherwise open app counts.

Where do you enter test credentials in Play Console?

Google publishes the path step by step (Prepare your app for review):

1. Open Play Console and go to the App content page (Policy and programs > App content).
2. Under Sign-in details, select Start. If you already submitted it, you will see Manage instead.
3. Select + Add new instructions and enter the access details: username, password, and how to reach the restricted screens.
4. Use Any other instructions for anything unusual — Google names “a one-time password, multi-factor authentication, or logins with more than two fields.”
5. Save, then open Publishing overview and click Send for review. Google is explicit that “Items are not sent for review until you click Send for review” (when changes are published).

You can add up to five sets of instructions — five instruction sets, not necessarily five separate accounts. After saving, budget for the clock: Google says “All app changes need to be processed before they can be published. Processing can take a few hours or up to seven days (or longer in exceptional cases)” and recommends “a buffer period of at least a week between submitting your app and going live” (same article).

What does Google require of the credentials you provide?

The requirements article is specific, and each line maps to a failure developers hit constantly (Requirements for providing sign in details for review):

• Accessible at all times, reusable, and valid regardless of user location. If content is geo-gated, provide “master” login credentials that work from anywhere.
• Maintained without error, and able to bypass 2-Step verification or a one-time password. Google's warning: “If the provided password expires, we may not be able to review your app and, therefore, the app may be rejected.”
• Provided in English, including the text of the login form itself.
• A static URL for QR codes and barcodes — an image the reviewer cannot scan from their device does not count.
• Clear instructions where users set their own password, such as a PIN.
• Full account details for third-party sign-in — “sign-in with Google, Facebook” or similar — with detailed instructions.
• Paywalled content still needs a way in: provide “additional instructions or access details that will allow us to fully and freely access and review the app behind the paywall.”

For the money side Play has a separate list. Under Settings > License testing you keep accounts that can buy your in-app products without being charged: each email list holds “up to 2,000 email addresses,” Google Groups have no user limit, and “Your own publishing account is always considered a licensed tester” (application licensing). That last line is why your own device never shows a real charge when you test a purchase.

Do you need to enter credentials in two places?

Usually no. Play Console has two credential fields, and Google has said plainly that the App content one covers the automated crawler: you do not need to provide credentials “if your app supports ‘Sign-in with Google,’ (which enables the crawler to log in automatically), or if you’ve already provided credentials on the App content page” (pre-launch report). The second field — Test and release > Testing > Pre-launch report > Settings — exists so you can give the crawler a pair of its own if you prefer.

Where it gets specific: “Credentials can only be automatically inserted into Android apps that use standard Android widgets. Credentials can't be used in apps that use OpenGL to render custom controls or apps that use a WebView for a web-based authentication flow” (same source). A login screen rendered inside a WebView — which is what most wrapped web apps ship — cannot be auto-filled by the crawler at all.

That does not get you out of App content. The crawler only produces the pre-launch report; human reviewers read your Sign-in details instructions. With a WebView login, write the path a person should follow (tap Continue with email, use the account below, ignore the magic link) and make sure the account has already finished the magic-link step, because a link that lands in your inbox is a link a reviewer cannot open.

Wrapped projects — Capacitor, Trusted Web Activity, Lovable builds — hit this most often; the surrounding Play requirements are covered in how to publish a Lovable app to Google Play.

Why does this matter for a closed test and production access?

Because the same credentials line sits in Google's production access checklist. Before you apply, Google asks you to double-check four areas, and the fourth is “Test credentials: If your app requires user authentication, provide valid, working login credentials in Play Console so reviewers can fully test your app's features” (testing requirements). The other three — app content and features, target audience and content rating, functional reliability — are things you want reviewers to get through quickly rather than stall on.

There is also a timing cost at the start. Google documents that “After publishing an open, closed, or internal test for the first time, the test link can take several hours to become available to testers” (set up a test), and every change must be processed before it publishes. A first submission that comes back for missing credentials adds another whole cycle on top of that, and your testers cannot install until it clears. Upload, review, rejection, fix, re-review — that is the stretch most first-time developers never budget for.

Based on our analysis of 1,500+ closed-testing campaigns, this is a form we complete before the first upload rather than after the first rejection, because the rejection route spends review days you do not get back.

The wider failure set sits in why production access applications get rejected, and the production access form questions walks the three sections you answer once the test finishes.

How do you fix a login-credentials rejection?

Google's resubmission path needs no support ticket: “Open Play Console and go to the Sign-in details page. Update your Sign-in details information and click Save. Go to the Publishing overview page ... Click Send for review” — and “You can complete these steps without contacting or waiting for a reply from the policy support team” (prepare your app for review).

Before you resend, put yourself where the reviewer stood: a clean device or a fresh install with autofill off, credentials copy-pasted exactly as they appear in the form rather than typed, on a different network from your own.

• The 2FA prompt. The reviewer has no code and no way to receive one. Turn it off on the test account, or publish the bypass Google asked for.
• An expired or rotated password. Google requires sign-in details to be “maintained at all times without any error,” so change it in Play Console at the same moment you change it in your backend.
• A geo-restricted login. Supply master credentials that are valid regardless of user location.
• An empty new account. Reviewers must reach the functionality you declared, so hand over an account that already has content and entitlements.
• OAuth rejecting the test device. In Google's community threads developers repeatedly report the “Invalid Login Credential” rejection caused by a backend that does not recognise the production signing certificate once Play App Signing is in play (community thread).
• A magic link or email code the reviewer cannot complete, because that inbox belongs to you.

Frequently asked questions

What is App access in Google Play Console? It is the questionnaire on your app's App content page where you give Google a working route into anything restricted by a login, subscription, membership or location check. Google now heads the section Sign-in details; both names open the same form.

Is App access the same as Sign-in details? Yes. It is one section carrying two labels across Google's documentation: the help article says Sign-in details, while Google's pre-launch report article and its pinned community guidance still call it App access. Enter it once, under Policy and programs > App content.

Do I need test credentials if my app uses Sign-in with Google? The pre-launch crawler logs in on its own when your app supports Sign-in with Google, and Google says you do not need to add credentials if you have already provided them on the App content page. Human reviewers are a separate matter: Google's published position is that when credentials are still requested, it is usually because a specific area or subscription is restricted.

How many sets of credentials can I give Google? Up to five sets of instructions, each with its own notes — the number to use when one account cannot demonstrate every gated path in your app.

Does missing App access stop my 14-day closed test? It does not alter Google's counting rule, which is 12 testers opted in continuously for the preceding 14 days. What it can do is get the release rejected, and a rejected release never becomes available for your testers to install, so day one moves. Fill in Sign-in details and send it for review before you invite anyone.