If any part of your app is behind a login, a membership, a location check or another kind of authentication, you have to give Google's review team a way in. You do it in Play Console under App content, in the Sign-in details declaration. Older guides and many developers still call it App access.
Missing or broken sign-in details are a common reason a release is held up or rejected, because the reviewer simply can't see the app. Here is where the declaration is and the rules Google publishes for it.
Where to add sign-in details
Open Play Console, select your app and go to Policy and programs, then App content. Find Sign-in details and click Start, or Manage if you filled it in before.
Click Add new instructions and enter the access details. There is also a field for any other instructions, for anything unusual about your login, such as a one-time password, multi-factor authentication or a login with more than two fields. Google's help says you can add up to five sets of instructions.
If your whole app works without any login, you don't need to give credentials. But if even one feature is locked, such as a profile, a paid section or an admin area, the reviewer needs to reach it.
Google's rules for the login you give
Google's help page on sign-in details is short and strict. The details must be accessible at all times, reusable and valid regardless of the reviewer's location. They must work without errors, and they must be in English.
If your app normally asks for a 2-step verification code or a one-time password, give a test account that skips that step. Google warns that if the password expires, it may not be able to review the app, and the app may be rejected.
If access depends on a QR code or barcode, Google asks you to generate a static URL and upload it to Play Console. If users set their own PIN, explain how. If the app uses Sign in with Google or Facebook, give the full account information with step-by-step instructions.
Paywalls, location and special cases
No login but content behind a subscription? Google still wants full access. Provide instructions or a test account that lets the reviewer use the paid part freely.
If your app only works in certain countries or areas, give credentials that work from anywhere. Google's example is a master login that isn't tied to a location.
Apps that need special hardware, an invitation from an organisation or a code from a real device need the same treatment: tell the reviewer exactly how to get past that step, or give them an account that is already set up.
Make the test account hard to break
Create a separate account just for review, with sample data already in it, so the reviewer sees a working app instead of empty screens. Don't use your personal account.
Make sure nothing in your backend can lock it: no automatic password expiry, no deleting inactive accounts, no rate limit that blocks a login from an unfamiliar country, and no trial that runs out. Then log in with it yourself from a fresh install before every release you send for review.
If a release is rejected or removed because of sign-in details, fix the account, update the Sign-in details page, save, and send the changes for review again from Publishing overview.
Closed testing first
For a new personal account, the first real review usually comes with your closed testing release, so set up the test account before you upload it. The same account is also handy for testers who want to try your app without registering.
If you still need 12 testers for those 14 days, PeerPlay is a free way to find them: Android developers test each other's apps every day through your real closed track.
Top comments (0)