Finishing your 14-day closed test is the hard part. The production access questions should be easy, but many developers get rejected at this last step because they treat the form like a formality and write vague, copy-paste answers.
This guide explains what Google's reviewers look for, what each question is really asking, and how to write answers that sound real instead of copied from a forum.
Critical Reminder
Your production access application is reviewed by people, not just an automated system. Answers that sound copied, dodge the question, or don't match what your app really does are a leading cause of avoidable rejections.
What the Form Actually Asks
The exact questions on the production access form change from time to time. The current version (as of 2026) covers these areas:
- What is your app's primary purpose and core functionality?
- Who is your target audience?
- How did you recruit your closed testers?
- What devices did your testers use?
- What feedback did you receive from testers?
- Have you previously applied for production access? If so, what was the outcome?
- Does your app have any sensitive permissions, features, or audience issues?
Question: What is Your App's Purpose?
This is the question that trips up the most developers. The reviewer wants to know what your app does, who uses it, and why it's useful. They also check that you picked the right category, for example that a "productivity tool" isn't really a gambling app, an adult content app, or a financial app that needs a license.
What to Write
Be specific and literal. Describe the core feature, the problem it solves, and who benefits. Do not use marketing language. Do not overstate features that do not exist in the version you submitted for review.
Example: Specific Answer
"[App Name] is a personal finance tracker that allows users to manually log daily income and expenses across multiple categories, set monthly budgets, and view spending trends as charts. It stores all data locally on the device. There is no account creation, no cloud sync, and no advertising. Target users are adults who prefer tracking finances without sharing data with a third-party service."What Not to Write
"My app is a useful productivity tool that helps users manage their daily life and improve their workflow through an intuitive and easy-to-use interface." This tells the reviewer nothing and sounds copied. It often leads to a request for more details or a rejection.
Question: How Did You Recruit Your Testers?
This is one of the most important questions on the form. The reviewer wants to know whether you used real people you actually worked with, or an automated service that could be faking activity.
Be honest about how you really found your testers. If you used a mix of people you know, Reddit communities, and a professional testing service, say so. Reviewers know not everyone has 12 developer friends who will test an app for free.
Example: Honest, Specific Answer
"I recruited testers through three channels: five personal contacts (colleagues and friends who own Android devices), four members of the r/androiddev developer community on Reddit who volunteered through a testing exchange post, and three verified testers from a professional testing service (Hire App Testers) who provided documented evidence of device model and engagement. All testers used physical Android devices and real Google accounts. I have opt-in records showing all 12 testers joined the closed track and remained active for the full 14-day period."Question: What Devices Did Your Testers Use?
Google checks for a mix of devices and looks for signs of emulators. If you used a cheap Fiverr testing gig, you won't be able to answer this truthfully, and the vague, made-up answers common with bot farms are easy for a reviewer to spot.
If you used a service like Hire App Testers, you'll have photo proof to refer to (screenshots of the real device model settings). Name the real device models and Android versions exactly as they appear in your records.
Example: Device Answer with Evidence
"Testers used a range of physical Android devices including Samsung Galaxy S23 (Android 14), Google Pixel 7 (Android 14), OnePlus Nord (Android 13), Xiaomi Redmi Note 11 (Android 12), and Motorola Moto G (Android 12). I have screenshots of each tester's device settings page available as documentation."Question: What Feedback Did You Receive?
This question checks that your testing was real. Reviewers want specific, believable feedback, not general statements like "everyone loved it" or "no issues were found."
Even if your app worked perfectly, testers always notice something: a confusing button, an unclear onboarding step, a feature idea, or a slow screen on one device. Write what really happened.
Example: Specific Feedback Answer
"Testers flagged that the onboarding tutorial was skippable without clearly explaining the core features first, which left a few testers initially unsure how to create their first budget. One tester on Android 12 reported a slow load time on the settings screen, which I traced to an inefficient database query and fixed in v1.0.2. Three testers requested the ability to export data as a CSV file, which I have added to the roadmap. Overall, core functionality worked across all tested devices without crashes."Question: Sensitive Permissions or Features
If your app asks for any of these permissions, you must explain them clearly and truthfully: Camera, Microphone, Location, Contacts, SMS, Phone, broad Storage access, Accessibility Service, Device Admin, or any special Play permission.
For each sensitive permission, explain exactly why the feature needs it, when the app asks for it, and what happens if the user says no. If your app uses a permission and the reason isn't obvious from the description, a reviewer will flag it.
The Specific Mistakes That Get Applications Rejected
- Mismatching descriptions: Your store listing says one thing, your questionnaire says another. Reviewers check both.
- Saying all testers gave only positive feedback: It sounds made up. Real testing always finds something.
- Vague device answers: "My testers used Android phones" with no models or versions.
- Reasons that don't match: Saying you need location access for "personalized content" when your app has no local content.
- Wrong category: Choosing an app category that doesn't match what you describe in the questionnaire.
Source: Google Play Console Help: App testing requirements for new personal developer accounts.
Frequently Asked Questions
How long does Google take to review a production access application?
Google says review usually takes seven days or less, but it can sometimes take longer. Apps in sensitive categories (finance, health, gambling-related) may take longer. If you haven't heard back after a few weeks, contact Google Play Developer Support to ask for an update.
Can I submit before the 14 days are complete?
No. The "Apply for production access" button only appears after your closed track meets the 14-day rules. Google's system controls the timing, so you can't apply early.
What happens if my application is rejected?
Google gives a reason for the rejection. In most cases you can fix the issue and apply again. If you were rejected for too little tester activity, you need another full test period. If it was a policy issue, fix the policy problem before you apply again.
Do I need to keep my closed test running while under review?
No. Once you've submitted your production access application, you don't need to keep the closed test running. Don't delete your closed track or make big changes to your listing while it's under review, since that could complicate things.