Where is App access in Play Console?

It is called Sign-in details now. Open Play Console, go to Policy and programs, then App content, and select Start under Sign-in details. If you have filled it in before you will see Manage instead of Start. Then click Add new instructions and enter your access details. The words App access do not appear anywhere on Google's own App content help article as of 21 October 2026, which is why searching for the old name finds blog posts rather than the form.

What do I actually put in the form?

A username or phone number, a password, and anything else a stranger needs to reach the locked screens. Google's requirements page lists standard sign-in details for testing, an active demo account with a pre-configured username and password, or other access resources such as QR codes or specific instructions. There is an Any other instructions field for the awkward parts, and Google names three: a one-time password, multi-factor authentication, and a login with more than two fields. You can store up to five sets of instructions.

Does my test account have to work without two-factor authentication?

Yes, in effect. Google says the details must be maintained at all times without any error, and that if your app normally needs a 2-Step verification code or a one-time password you should provide reusable login credentials that can bypass those requirements. It then states the consequence: if the provided password expires, Google may not be able to review your app, and the app may be rejected. The same page asks for details that are accessible at all times, reusable, and valid regardless of user location.

What if my app has no login but has a paywall?

You still owe review a way in. Google's requirements page says that if your app does not require sign-in details but you have functionality or content behind a subscription paywall, you should provide additional instructions or access details that allow review to fully and freely access and review the app behind the paywall. A free trial that a reviewer cannot start is the same problem as a login they cannot pass.

Can I just give review my own account?

No. Google's permissions declaration guidance says to provide only account credentials specifically used for testing, and not to provide any production user's credentials. Make a test account, keep it alive, and keep its password out of your expiry policy. It is also the account that will be used by a stranger who has never seen your app, so seed it with enough data that the main screens are not empty.

My app was rejected over sign-in details. What now?

Google publishes the route and says you can take it without contacting or waiting for a reply from the policy support team. Open the Sign-in details page in Play Console, update the information and save, go to the Publishing overview page where the edit appears under Changes ready to send for review, then click Send for review. That is the whole loop, and it is shorter than the equivalent on the other store.

Articles · How-To GuidesUpdated October 2026

Google Play app access instructions are now called Sign-in details.

Q: Do I have to fill it in if nothing in my app is gated?

The two Play Console Help pages I read put it conditionally. Both describe the obligation as something that applies when your app or part of it is restricted. The Play Console Requirements policy is blunter, and lists under things you must do before you submit: provide an active demo account, login information, and all other resources needed for Google Play to review your app. The radio button people quote, All functionality is available without special access, is real, but on 21 October 2026 it sits in the Permissions Declaration Form for SMS or Call Log access, not in Sign-in details.

App access instructions are the credentials and notes you leave in Play Console so a reviewer can open the locked parts of your app. The form is on the App content page, and on 21 October 2026 Google labels it Sign-in details. The phrase App access does not appear anywhere on the help article that documents the App content page. That matters more than a name change usually does, because the search result you are probably holding tells you to look for a section that is no longer labelled that way, and because a blank or broken answer here reads at review as an app that does not work. Rejections of that kind do not show up in any published figure, and no store publishes app store rejection rates at all.

What follows is where the form lives today, what Google requires the credentials themselves to do, what happens when the field is empty or stale, and whether an app with no login owes anything. Every field name and rule below comes from Google's own Play Console Help pages, read on 21 October 2026. Those pages carry no last-updated date of their own, so the read date is the only date there is.

Start here

The short version

One working account, and it has to keep working after you press send.

Play Console wants a login that a stranger in another country can use at any time, more than once, in English, without a code arriving on your phone. That is the whole requirement in one sentence. Everything else on this page is a special case of it: a QR code becomes a static URL, a social login becomes the other service's account details too, a geo-gate becomes a master credential, and a paywall becomes instructions for getting behind the paywall.

The failure most people hit is not an empty field. It is a field that was right in March. Google says the details must be maintained at all times without any error, and that an expired password can mean it cannot review the app, so the app may be rejected. A test account that rotates its password on a schedule will fail a review months after you forgot the account existed.

Where do app access instructions live in Play Console?

Open Play Console and go to Policy and programs, then App content. Under Sign-in details, select Start. If you have filled it in before you will see Manage rather than Start. Click Add new instructions, enter your access details, and save. That is the path Google publishes, read on 21 October 2026, and the heading on its own help page is Sign-in details. The old label is gone from the text. Interestingly the plumbing underneath is older still: the Play Console link on that page points at an app content address ending in testing-credentials, which is probably the oldest name of all three.

The App content page is where Google collects the declarations it needs before a human looks at your build. The same page holds your privacy policy URL, the ads declaration, target audience, content ratings and the data safety answers. It has two tabs, Needs attention and Actioned, and Google says you should review what you have provided regularly and keep it up to date. Sign-in details is one entry in that list, which is why it is easy to fill in once and never look at again.

Two details in the form are worth knowing before you open it. There is an Any other instructions field, and Google tells you what it is for: anything special about your login mechanism, naming a one-time password, multi-factor authentication, and a login with more than two fields. And you can store up to five sets of instructions, as of 21 October 2026, so an app with a customer login and a staff login does not have to cram both into one box.

Play Console Help, Prepare your app for review, Sign-in details section, read 21 October 2026

Check yours

What your sign-in details have to cover

Tick how someone gets into your app. Each answer is the rule Google publishes for that case, read on 21 October 2026.

Nothing ticked yet. Start with the way you log in yourself, then add the awkward ones, because the awkward ones are what review gets stuck on.

What does Google require the credentials to do?

Google has a separate page for this, and it is the one worth reading twice. The sign-in details must be accessible at all times, reusable, and valid regardless of user location. They must be maintained at all times without any error. They must be in English, and if your credentials are normally in another language you have to provide an English version. Those are not style notes. They are the conditions that decide whether a reviewer in a different country, on a different day, can get in.

Then come the awkward logins, each with its own instruction. If your app usually needs a 2-Step verification code or a one-time password, provide reusable credentials that can bypass that. If the sign-in details are not numeric or alphanumeric, a QR code or a barcode for example, generate a static URL and upload that instead. If people set their own PIN to reach in-app content, provide clear instructions for doing so. If sign-in runs through another service, such as signing in with Google or Facebook, provide all of that account information with detailed instructions. If the password depends on location, a geo-gate, provide credentials that work anywhere, and Google's own example is master login credentials.

One case catches people who are sure this page is not about them. Google says that if your app does not require sign-in details but you have functionality or content behind a subscription paywall, you should provide extra instructions or access details so review can fully and freely access and review the app behind the paywall. An app with no accounts at all can still owe something here, and a free trial a reviewer cannot start counts as a locked door.

There is one rule that is not on that page but belongs next to it. Google's guidance for the Permissions Declaration Form says to provide only account credentials specifically used for testing, and not to provide any production user's credentials. Treat that as the general rule. A review account is a shared account whose password sits in a form, so it should never be a real person's login and never an admin.

Play Console Help, Requirements for providing sign in details for review, read 21 October 2026

What happens at review when the field is empty?

Google does not publish a sentence that says an empty field causes an automatic rejection, and I am not going to invent one. What it does publish is the consequence of credentials that do not work. On its requirements page it says that if the provided password expires, it may not be able to review your app, and therefore the app may be rejected. The logic is the same for a field with nothing in it. A reviewer who cannot get past your first screen has seen an app that does not function, and that is the finding you will read in the rejection notice.

The policy side is firmer. Play Console Requirements, the Google Play policy article that the sign-in details page cites, lists under what you must do before you submit, at clause 3.3 as of 21 October 2026: provide an active demo account, login information, and all other resources needed for Google Play to review your app. Its own summary of things not to do ends with a line about this, telling you not to submit outdated sign in details. A stale credential is treated as a policy problem, not an accident.

The recovery route is published, and it is short. Google says that if your update is rejected or your app is removed you can resubmit without contacting or waiting for a reply from the policy support team. Open the Sign-in details page, update it, save, go to Publishing overview where the edit appears under Changes ready to send for review, and click Send for review. No letter, no case, no queue for a human to reply to you first.

That is the part worth appreciating if you have done this on the other store. On the App Store the comparable mistake sends you into a reply thread with App Review, and if the decision itself is wrong your next step is to appeal an App Store rejection. On Google Play a bad credential is a form edit and a resend.

Play Console Help, Requirements for providing sign in details for review, read 21 October 2026

Is this required for every app or only for gated ones?

Google says it two different ways, and the difference is worth ten minutes of your attention. The help text is conditional. It opens with a condition about your entire app or parts of it being restricted based on login credentials, sign in details, memberships, location, or other forms of authentication, and only then tells you that you must provide all required details to enable access. By that wording, an app with nothing locked has nothing to hand over.

The policy is unconditional. Play Console Requirements puts the demo account and login information under a flat heading about what you must do before you submit your app. Read literally it asks for all other resources needed for Google Play to review your app, which for an app with no gate is nothing, and for an app with a staff mode, a paywall or a region lock is more than most people put in the box. The practical reading: the obligation is to a reviewable app, not to a filled-in form.

Now the radio button. Plenty of guides tell you to pick either All or some functionality is restricted or All functionality is available without special access. Both phrases are real and current. Neither is in the Sign-in details section. On 21 October 2026 they sit in Google's Permissions Declaration Form guidance, the form you complete when your app asks for SMS or Call Log access, at the step about providing instructions for accessing restricted app content. That form also wants a video demonstration of your core functionality, with a YouTube link preferred. If you read a guide that puts those radio buttons in App content, it has merged two different forms.

Neither of the two Play Console Help pages I read, the App content article and the dedicated requirements article, describes a declaration that an app without a login has to complete. If your Play Console shows one under Sign-in details, answer it honestly and move on. Honest is also the only sane answer to the surrounding declarations, including the app store content rights question that Apple asks on its side of the fence.

The same reviewer problem, handled differently by each store

Apple asks for the same thing in fewer words. Its App Store Review Guidelines, read on 21 October 2026, tell you to provide App Review with full access, and where your app has account-based features to give either an active demo account or a fully-featured demo mode, plus any other hardware or resources that might be needed, naming login credentials or a sample QR code. Guideline 2.1 adds that if you cannot provide a demo account because of legal or security obligations you may include a built-in demo mode instead, with prior approval by Apple, and that the demo mode has to show the full feature set. Where the column below says a thing is not stated in guideline 2.1, that means I read the guideline and it is not there, not that Apple permits the opposite.

The question	Google Play	App Store	Same on both
What the form is called	Sign-in details, on the App content page	App Review notes, plus demo account fields	No
A demo mode instead of an account	Not offered in the pages below	Allowed, with prior approval by Apple	No
Credentials must survive 2-Step verification	Yes	Not stated in guideline 2.1	No
A sample QR code counts as a resource	Yes	Yes	Yes
Must be in English	Yes	Not stated in guideline 2.1	No
How many sets you can store	Up to five	Not stated in guideline 2.1	No
Fixing it after a rejection	Edit, save, send for review again	Reply, resubmit, or appeal	No

Google Play column from the two Play Console Help pages linked above. App Store column from the App Store Review Guidelines, read 21 October 2026.

Where this lands if a builder generated your app

Nothing here changes because an AI wrote the code. The form is about your app and your accounts, so you fill it in, and you keep the test account alive long after the build is done.

Newly is an AI app builder. You describe an app in plain English and it writes a real React Native and Expo project you own. It uploads iOS builds to TestFlight, publishes to Google Play internal testing and builds a standalone Android APK, and it keeps two-way GitHub sync so the code is yours to read. It costs $25 a month, with no free tier. It does not submit to the App Store for you, because Apple wants the owner of the content to submit. On the Play side the useful consequence is that internal testing gets you a real installable build before any of this paperwork matters, so you can find out whether a stranger can sign in before a reviewer does.

The part worth planning for: a new generated app usually starts with no accounts and no server, so there is nothing to declare here at all. The moment you ask for sign-in, a paywall or staff-only screens, you have created the thing this form exists for. Make the test account on the same day you add the login, not on submission day. And if your app is thin enough that a reviewer gets through it in ten seconds, sign-in details are the least of your problems: read guideline 4.3 spam rejection before you submit anywhere.

Questions people ask about Play Console sign-in details

They are the credentials and notes you leave in Play Console so the review team can get into the parts of your app that are locked. Google Play Console calls the form Sign-in details, on the App content page, as of 21 October 2026. The help article says that 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.

Make the test account on the day you add the login

One account, no expiry, no second factor, in English, with enough data in it that the main screens look like an app. Then the form takes two minutes and keeps working for the next release.

Start building