Twelve testers and 14 days get you to the Apply button, not to a production release. Play Console still wants a finished store listing, the App content declarations and written answers about your closed test, and each can cost a week if you leave it to the end. Below are the nine items, what Google checks in each, the usual mistakes, and how to collect your questionnaire answers while the test runs. Google decides production access, and no checklist changes that. A checklist only removes the avoidable delays.
When you can apply
Play Console offers the production access application on your app's dashboard once at least 12 testers have been opted in to your closed test for the last 14 days in a row. The free closed testing tracker shows which day you are on and the earliest date you can apply. Google's help page says the review usually takes seven days or less.
The nine items to finish first
Some of these are looked at with your production access application. Others are checked when you send your first production release for review, and Play Console will not send it while one is missing. Either way, do them during the 14 days. You are waiting anyway.
1. Store listing
What Google checks: an app name of up to 30 characters, a short description of up to 80, a full description of up to 4,000, a 512 x 512 app icon, a category and a contact email. Google's metadata policy covers all of it. Titles, icons and developer names cannot carry words like "best", "top", "#1" or "free", or prices and promotions, and a description cannot be a keyword list or claim things the app does not do.
Common mistakes: a title padded with search terms, a description written for the app you plan to build rather than the build you uploaded, and a contact email nobody reads. It is shown on your listing.
2. Screenshots and feature graphic
What Google checks: at least two phone screenshots and a 1024 x 500 feature graphic. Phones take up to eight screenshots. The metadata rules apply to images too.
Common mistakes: screenshots from an older build that no longer match the app, mockups of screens that do not exist yet, and screenshots that are mostly text and show nothing of what the app looks like.
3. Data safety form
What Google checks: what user data your app collects and shares, why, whether it is encrypted in transit, and whether users can have it deleted. It covers every SDK in your build, so analytics, crash reporting, ads, sign-in and payments all count. If users can create an account, Google also wants a web link where they can request account deletion. Every app fills this in, including apps that collect nothing.
Common mistakes: answering "no data collected" with Firebase Analytics, Crashlytics or an ads SDK in the build, and leaving out the deletion link. Most SDK makers publish what their library collects for this form, so read theirs first.
4. Content rating
What Google checks: the IARC questionnaire in App content, which gives your app an age rating for each region. Play Console will not publish an app without one.
Common mistakes: saying users cannot interact when the app has chat, comments or shared profiles, forgetting location sharing, and ignoring what a web view can show. Answer for what the app can show. Google can change a rating that does not match the app.
5. Target API level
What Google checks: the targetSdkVersion of the build you upload. Google raises the minimum once a year, around the end of August. From 31 August 2025, new apps had to target Android 15 (API level 35), and the floor usually moves up one level a year, so check Google's target API level page the week you upload. Play Console refuses an upload below it.
Common mistakes: a framework template pinned to an older target, and raising the target on the last day. A new target brings new behaviour: apps that target Android 15 draw edge to edge on Android 15 devices, so a layout that looked fine can end up under the status bar. Raise it before the closed test starts, so testers use the build you will ship.
6. Privacy policy URL
What Google checks: a privacy policy link in App content, and one inside the app if it handles personal or sensitive data. The page must be public, live, not geofenced and not a PDF. It should name your app or you as the developer, say what data the app collects and how it is used, and give a contact.
Common mistakes: a Google Doc that needs sign-in, a template that still names somebody else's app, a link that broke when you moved your website, and a policy that says something different from your data safety form.
7. App access for reviewers
What Google checks: if any part of the app sits behind a login, a subscription, an invite code or a location, App content asks for instructions and working credentials so a reviewer can get in. If the reviewer cannot get in, the review can fail on that alone.
Common mistakes: a test account that expires or gets wiped by a cleanup job, a login that sends a one-time code to your own phone, a staging server that is down that day, and a paywall with no way past it. Use an account that never expires, without two-factor, and log in with it yourself on the day you apply.
8. Ads declaration
What Google checks: whether your app contains ads, which decides the "Contains ads" label on your listing. Separately, an app that targets Android 13 or later and uses the advertising ID has to say so in the advertising ID declaration and in its manifest.
Common mistakes: answering no because ads are switched off for now while an ads SDK sits in the build, and missing the advertising ID declaration because an analytics SDK reads the ID. The ads answer, that declaration and the data safety form should agree.
9. Countries and release track
What Google checks: where the production release is available and which build goes out. Once production access is granted, you create a production release, and you can promote the build you tested on the closed track instead of uploading a new one.
Common mistakes: shipping a build with changes your testers never saw, leaving out countries where your first users are, and stopping the closed test on the day you apply. Keep it running until Google answers, in case the answer is more testing.
Play Console also asks for a target audience (ages under 13 bring in Google's Families policy), plus declarations that apply only to some apps, such as financial features, health and news. Read each one instead of clicking through.
How the production access questionnaire works
The application is nine questions in three parts. Google does not publish the form and the wording shifts a little between accounts, but in 2026 it asks:
- About your closed test: how you recruited testers, how easy that was (multiple choice), the engagement you got from testers, and a summary of their feedback and how you collected it.
- About your app: who it is for, how it gives those people value, and how many installs you expect in the first year (multiple choice).
- Your production readiness: what you changed because of the closed test, and how you decided the app is ready.
Two are multiple choice. Of the other seven, three carry the evidence of engagement: the engagement question, the feedback summary and what you changed. Google's refusal email, "More testing required to access Google Play production", gives two possible reasons, unengaged testers or feedback not acted on, and both point at those three answers. If you already have that email, start with what to do after a production access rejection.
Preparing your answers during the 14 days
The answers are easy to write from notes and hard to write from memory. Start these on day one:
- Note how you found each tester and when they joined. The first question asks, and the honest answer is the safe one.
- Give testers three to five concrete tasks, like creating an account and finishing the main flow once. "Try the app" gets you nothing to report.
- Pick one feedback channel and tell testers where it is: an email address, a form, or the feedback contact on your closed track.
- Keep a log with one line per event: date, tester, what they did, what broke, what you changed.
- Ship at least one update that fixes something a tester reported, and note the version and date.
- Around day 7 and near day 14, ask each tester what they used and what confused them, and count the replies. "11 of 14 testers finished the main flow" is the kind of line the engagement question wants.
When the 14 days are up, our free production access answer drafter turns those notes into a first draft of all nine answers and leaves a bracket wherever only you know the fact. Rewrite it in your own words before you submit.
If you would rather have it done for you
We sell this, so weigh it that way. TestFi Launch is $499 for one Android app: a 20-tester closed test for 14 days, with our usual promise of 12 still opted in on day 14 or a free re-run. Invited TestFi Pro testers make 5 screen recordings on days 2 to 5, 15 to 20 minutes each, thinking out loud, and a fix list ranked by severity, with timestamps, reaches you by email within 5 business days of the last approved recording. You tick the nine items above and a person reviews them on days 12 to 14. The production access answers are drafted from your testers' notes, edited by a person and on your campaign page within 2 business days after day 14. You read them and submit them yourself.
Frequently asked questions
What does Google check before granting production access?
Whether your closed test met the rule (12 testers opted in for the last 14 continuous days), and whether testers used the app and you acted on what they said. Google does not publish how it weighs engagement. Your store listing and App content declarations also have to be complete before the first production release goes out.
How long does the production access review take?
Google's help page says it usually takes seven days or less and can occasionally take longer. You get an email when it is done.
Do I need a privacy policy if my app collects no data?
Yes. Google asks every app for a privacy policy link, and every app fills in the data safety form, including apps whose answer is that they collect nothing.
Can I apply for production access before the 14 days are over?
No. Play Console offers the application once at least 12 testers have been opted in for the last 14 continuous days.
What happens if Google says more testing is required?
You test with closed testing for an additional 14 days with real testers, then apply again. The email gives two possible reasons, unengaged testers or testing best practices not followed, without saying which applied. Plan for both.