Do I need to provide a demo account and login details for Google Play review?

Do I need to provide a demo account and login details for Google Play review

Yes, if any part of your app is behind sign-in, restricted content, membership access, or another access wall, Google Play expects you to provide a demo account, valid login details, and any other steps needed for reviewers to reach that content. Google says this in its Play Console requirements and in its review guidance.

The part people get wrong is assuming that a store listing, screenshots, or a written explanation is enough. It is not enough when the reviewer cannot actually enter the app and check the blocked flow. Google Play says review needs access details that let the team log in and reach all app functionality, and it can reject the app if those details are missing or unusable.

A demo account is not required for every app. If your app has no login wall, no restricted sections, no paywall, and no special access requirement, you do not need to invent a demo account just to fill the form. What you do need is clear access instructions whenever the reviewer would otherwise be stuck. Google’s review guidance covers login credentials, QR codes, and instructions for restricted areas.

Google Play is explicit about what counts as acceptable access help. It can be standard test sign-in details, an active demo account with username and password, QR codes, or detailed instructions for restricted areas. If your app uses Google sign-in, Facebook sign-in, a location-based gate, or a one-time setup flow, you need to provide everything the reviewer needs, not just a single field in Play Console.

The account must work at review time. Google says the credentials must be accessible at all times, reusable, valid regardless of location, and maintained without error. If the password expires, the login is tied to a one-time code, or the account depends on a device-specific or location-specific condition, the reviewer may fail the review and reject the app.

The inconvenient part is that a working demo account has to survive the real review process, not just your internal test. If the app has a subscription paywall, Google asks for extra instructions or access details so the reviewer can fully and freely access the app behind the paywall. If the app depends on external hardware or another service, you need to explain that path clearly and make sure the reviewer can still verify the app’s behavior.

Do not use the review process as a place to buy testers, buy installs, or try to game access. Google Play’s policy guidance says inauthentic engagement is a policy problem, and buying testers is not a normal shortcut. For review access, the safe path is simple: provide real credentials or real instructions that let Google review what is already on your own app.

If your app uses two-step verification or one-time passwords, Google wants reusable credentials that bypass that friction for review. If your login credentials are not in English, Google asks you to provide an English-language version in Play Console. If the app uses non-text access methods, like a barcode or QR code, Google asks for a static URL or equivalent reusable access method.

The practical checklist is straightforward. First, open Play Console and go to the App content or app access area. Second, note every place where a reviewer would hit a wall, including login, paywall, subscription gate, hardware pairing, or region restriction. Third, provide one clean path through that wall, test it yourself on a fresh device or account, and make sure it still works after a few days.

If you want an example, think about a fitness app with free public pages and a locked training plan. The public pages may be easy to review, but the locked plan still needs access details if that content matters for policy review. If the reviewer cannot see the plan, they cannot confirm what the app actually does, and the submission can be rejected for missing access.

A second example is a field-service app that only works after logging into a company account. In that case, a demo account is not optional, because the app is effectively invisible without it. Google’s guidance says to provide the login information, related resources, and clear instructions so the review team can reach the full app experience.

The shortest correct answer is this: provide a demo account and login details whenever Google Play cannot review the app without them. If reviewers can already see everything they need, you can leave credentials out. If they cannot, the missing access details are a review blocker, not a minor formality.

If you are building with DevConnect, the same basic rule applies to any app you ship from your own account: make reviewer access easy, reusable, and honest. That keeps the review path predictable and avoids the kind of access failure that turns into a rejection. https://devconnectplatform.com

What if my app has a sign-in wall but only part of the app is restricted

Provide access for the restricted parts, not just the landing page. Google Play says reviewers need whatever is required to access all app functionality, so even a small locked area can trigger a login request in Play Console.

Can I use my own personal account for review

You can if it is a valid, reusable, reviewer-safe account and it gives access to the right parts of the app. The key requirement is not whose account it is, the key requirement is that the account works reliably for Google Play review.

What happens if Google cannot log in

Google says the app may be rejected if the team cannot review it. In practice, that means missing, expired, broken, or incomplete credentials can delay release until you fix the access path and resubmit.

Do I need to share admin or backend credentials

No, not by default. Share only the access needed to review the app safely and fully. If a restricted feature needs a special role, provide a reviewer-safe path into that role instead of exposing unrelated admin access.