If your app has any kind of sign-in, Play Console wants a Sign in details declaration (it used to be called "App access"). It tells reviewers how to get past your login screen.
It's easy to skip during setup, and the top of the form is blunt about what happens then:
To review your app, we need to be able to access all parts of it using sign in details. If we can't gain full access to your app, it may be rejected in review.
The part that trips people up most: an app that only uses Google Sign-In still has to answer "Yes". Here's why, plus the exact text we submit.
TL;DR
- Any sign-in at all, including Google Sign-In only, means "Yes" to "Is any part of your app restricted?"
- Everything in the form must be in English, and reviewers reuse it on every update you submit
- Reviewers won't create an account, won't use their own, and can't contact you. If it isn't written down, they won't see it
- Google Sign-In only: leave username and password empty and explain it under "Any other information" (template below)
- Your own account system: give them a dedicated test account with paid features already unlocked
Where the form lives
Haven't filled it in yet: go to the Dashboard. Under "Finish setting up your app", expand "Provide app information and create your store listing" with View tasks, and you'll find Sign in details.
Already filled it in: the task may be gone from the Dashboard. Use the left menu instead: Monitor and improve → Policy and programs → App content. The new sidebar is icons only, so expand "Monitor and improve" to see it.
On the App content page:
- Need attention tab: find Sign in details → Start declaration
- Actioned tab: find Sign in details → Manage
Step 1: "Is any part of your app restricted?"
Answer Yes if your app uses any of these:
- account sign in details, such as an email address, username, Google Account sign in, and / or SSO
- payments, such as one-time products, memberships, subscriptions, and / or access tiers
- referral codes and / or QR codes
- one-time PINs and / or 2-step verification
- biometric authentication
- actions to be carried out on another device
The first item names Google Account sign in explicitly. No password system of your own doesn't change the answer.
Answer No only when none of the six apply: no sign-in, no payment, everything usable the moment the app opens.
After "Yes", click Add details.
Step 2: the fields
| Field | What goes in it |
|---|---|
| Name | A label for this set, like Google Login or Test account |
| Username and password | A working pair if you have your own accounts. Empty for Google Sign-In only |
| Any other information required to access your app | Everything else: how to get past 2-step verification, how to reach a demo or guest mode, a static URL for a QR code |
| Final checkbox | Confirms these details give "full access to all the features and content within this app, including premium or paid content" |
Read the line right above the checkbox, because it explains most rejections here:
Reviewers are unable to create accounts, use their own existing accounts, or use free trials to access your app. They are also unable to contact you for more information.
You can add several sets. If admins and regular users see different things, or you support both a password and Google Sign-In, add one set per path and name each clearly.
Template: Google Sign-In only
BetaLobby only uses Google Sign-In. This is what we submit:
- Name:
Google Login - Username and password: empty
- Any other information required to access your app:
This app exclusively uses Google Sign-In for authentication. There is no traditional username or password login system. Please use any standard Google account (such as the one already signed into your test device) to log in. All features and content will be fully accessible automatically upon signing in with a Google account. We've used this since our first submission and haven't had a problem with this declaration. That's our experience, not a promise from Google.
One caveat: if users have to do something after sign-in before the main features work (join a team, finish onboarding, pay), a fresh Google account won't see everything. In that case, prepare a test account that's already past those steps and describe it.
Below the list there's also a toggle that lets Google use these details for extra testing on Google and trusted partner devices. We leave it on.
Your own account system: a test account checklist
- Dedicated account: not your personal one, never a real user's
- 2-step verification: turn it off for this account, or explain how to get past it
- Paid content unlocked: the checkbox covers premium and paid content, so subscriptions and memberships must already work
- Keep it alive: every update is reviewed again with these details. Changed the password, or the account expired? Update the declaration under Actioned → Sign in details → Manage
Before you submit
- Any sign-in (Google only included) → answered "Yes"
- "Any other information" explains, in English, how to get in
- The test account signs in right now, and paid features work
- After changing passwords or sign-in methods, the declaration is updated
Why this matters for production access
Reviewers use these details whenever they review your app, and for new personal developer accounts that includes the production access application after closed testing. If they can't get in, they can't see what you built. It's one item in the checklist in "More testing required" on Google Play: 5 reasons and fixes.
If you're still in closed testing and short on testers, BetaLobby is where indie Android developers team up: 16 developers form a team and test each other's apps for 14 days, with installs and daily check-ins verified automatically. It's free.
Originally published on betalobby.com.
