Google Play Production Access Requirements: All Mandatory Requirements Explained
If you created a personal Google Play Console account recently, you quickly discovered that publishing an Android application is no longer as simple as uploading an APK and writing a store description.
Google has transformed the publishing workflow into a multi-tiered regulatory and technical gauntlet. Many developers focus exclusively on the famous 12-tester, 14-day closed testing rule, only to have their production access application rejected because they overlooked other mandatory requirements quietly enforced in the background.
To pass review on your first attempt, you must treat production access as an integrated compliance checklist spanning account verification, app architecture, testing telemetry, and policy declarations.
Here is the complete, exhaustive guide explaining every mandatory requirement you must satisfy to unlock Google Play production access.
Quick Answer: To gain Google Play production access, you must satisfy seven mandatory requirements: 1) Verified developer identity; 2) Target SDK 34/35 compliance with 64-bit Android App Bundle (
.aab); 3) Active test credentials inPlay Console > App access; 4) 14 continuous days of closed testing with at least 12 opted-in physical testers; 5) Android Vitals crash rate below 1.09% and ANR below 0.47%; 6) Compliant Privacy Policy and Data Safety forms; and 7) A detailed, evidence-backed production access questionnaire.
- The Core 14-Day Gate: Keep 12+ physical testers continuously enrolled without dropouts.
- Stability Matters: Keep crash rates strictly below 1.09% in Android Vitals.
- Credential Access: Provide demo login credentials so reviewers can inspect gated features.
The 7 Mandatory Pillars of Production Access
To eliminate confusion, break down Google Play's production requirements into seven foundational pillars:
[The 7 Pillars of Google Play Production Access]
βββββββββββββββββββββββββββββββββββ βββββββββββββββββββββββββββββββββββ
β Pillar 1: Account Verification β β Pillar 2: Technical Standards β
β - Government ID / D-U-N-S β β - Target SDK 34/35 β
β - Phone & Email verification β βββ> β - 64-bit Android App Bundle β
β - Dun & Bradstreet registry β β - Hardware-backed signing key β
βββββββββββββββββββββββββββββββββββ βββββββββββββββββββββββββββββββββββ
β β
βΌ βΌ
βββββββββββββββββββββββββββββββββββ βββββββββββββββββββββββββββββββββββ
β Pillar 3: App Access & Login β β Pillar 4: Closed Testing Gate β
β - Functional demo credentials β β - 12+ Physical device testers β
β - 2FA / OTP bypass rules β βββ> β - 14 Uninterrupted days β
β - Unrestricted reviewer access β β - Rolling DAD telemetry β
βββββββββββββββββββββββββββββββββββ βββββββββββββββββββββββββββββββββββ
β β
βΌ βΌ
βββββββββββββββββββββββββββββββββββ βββββββββββββββββββββββββββββββββββ
β Pillar 5: Android Vitals β β Pillar 6: Policy & Privacy β
β - Crash rate < 1.09% β β - Complete Data Safety section β
β - ANR rate < 0.47% β βββ> β - Valid Privacy Policy URL β
β - 0 Pre-Launch Robo failures β β - Target Audience / Families β
βββββββββββββββββββββββββββββββββββ βββββββββββββββββββββββββββββββββββ
β
βΌ
ββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
β Pillar 7: Production Questionnaire (Evidence-Based Human Review) β
β - Detailed feedback receipts, device models, and iteration logs β
ββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
Failing even one of these pillars results in an immediate rejection or blocks the "Apply for production" button from unlocking.
Let's examine the exact rules for each requirement.
Requirement 1: Developer Identity Verification
Before you can even initiate closed testing, Google requires proof of legal identity under its enhanced developer verification framework:
- Personal Accounts: You must provide a valid government-issued photo ID (passport, driver's license), a verified physical residential address, and an active phone number.
- Organization Accounts: You must provide an official D-U-N-S Number issued by Dun & Bradstreet, official corporate registration documents, and a verified organizational domain and phone number.
If your identity verification is pending or flagged for discrepancies between your legal name and banking details, your closed testing progress cannot advance to production.
Requirement 2: Technical Architecture & Target SDK Standards
Google Play enforces strict binary format and target API standards for all new applications:
Format Requirement: Android App Bundle (.aab) ONLY (Raw .apk is rejected)
Architecture: 64-bit native library support (arm64-v8a, x86_64)
Target API Level: Target SDK 34 (Android 14) or SDK 35 (Android 15)
Max Size: 150MB compressed download size via Play Feature Delivery
Essential Build Checks:
- ProGuard / R8 Verification: Ensure your release build has proper keep rules so that minification doesn't strip serialized JSON models or crash on tester devices.
- Play App Signing: Opt into Google Play App Signing so Google can generate device-optimized split APKs for your closed testers.
Requirement 3: Full App Access Credentials for Reviewers
One of the most common reasons developers get rejected after completing 14 days of testing is failing to configure the App Access section:
Play Console > Select App > App compliance > App access
If your application requires account creation, phone number verification, biometric login, or a paid subscription:
- You must select "All or some functionality is restricted".
- Provide a working demo username and password (e.g.,
google-tester@yourdomain.com). - If your app uses SMS one-time passwords (OTP), you must configure your backend to accept a static bypass code (like
123456) for the reviewer's test account. - If your app features a paywall, unlock all premium features for this test account.
If a human Google reviewer downloads your app and cannot log in past the splash screen, they reject your production request immediately with "Unable to evaluate core app functionality."
Requirement 4: The 12-Tester, 14-Day Closed Testing Gate
This is the primary operational hurdle for personal developer accounts:
[The Closed Testing Formula]
At Least 12 Physical Testers + 14 Continuous Calendar Days = Production Button Unlocks
The Strict Rules:
- Physical Hardware Only: Testers must install the app on genuine physical Android devices. Emulators, virtual machines, and cloud testbeds fail Google Play Integrity attestation.
- Continuous Opt-in Status: All 12+ testers must remain opted into the track via the Play Store link and keep the app installed on their phones. If an uninstall drops your active count to 11 on Day 12, your 14-day clock resets back to Day 1.
- Recruit a Buffer: Always recruit 16 to 20 testers to protect yourself against accidental dropouts.
For setup details, see our guide on how to correctly set up the closed testing link for 14-day testing.
Need 12+ Guaranteed Testers for 14 Days?
Avoid dropouts, clock resets, and questionnaire rejections. AppConsoleLab provides verified physical Android testers with guaranteed continuous opt-in retention.
Requirement 5: Android Vitals & Stability Thresholds
During your closed test, Google continuously records diagnostic stability metrics under Android Vitals:
Bad Behavior Thresholds (Max Allowed):
User-Perceived Crash Rate: 1.09%
User-Perceived ANR Rate: 0.47%
In a small cohort of 14 testers, just one tester experiencing two crashes can push your crash rate above 2%, breaching Google's threshold.
How to Maintain Pristine Vitals:
- Check
Play Console > Quality > Android vitals > Crashes and ANRson Days 3, 7, and 12. - Fix all background exceptions, out-of-memory errors, and main-thread I/O operations.
- Review the Pre-Launch Report (
Play Console > Quality > Pre-launch report) to resolve any red stability crashes detected by automated Robo test crawlers.
To learn more about technical stability, read our guide on how to prevent your app from being rejected for Google Play production access.
Requirement 6: Data Safety, Privacy, and Content Compliance
Before submitting for production access, your app's regulatory declarations must be 100% complete and accurate in Play Console:
| Policy Requirement | What Google Requires | Common Rejection Trap |
|---|---|---|
| Privacy Policy | Live, publicly accessible URL detailing data collection | Dead link, 404 error, or generic generator text |
| Data Safety | Accurate disclosure of collected data types (Location, Photos, Device IDs) | Failing to disclose third-party SDK data (e.g. AdMob/Firebase) |
| Target Audience | Declaring whether your app targets children under 13 | Claiming "Not for children" when the app uses cartoon graphics |
| Financial / Health | Special declarations if handling medical data or loans | Missing regulatory licenses or lending disclosures |
Google's automated policy crawlers cross-reference your app's declared permissions in AndroidManifest.xml against your Data Safety answers. If your app requests ACCESS_FINE_LOCATION but your Data Safety form states you do not collect location data, your application is blocked.
Requirement 7: The Production Access Application Questionnaire
Once your 14 continuous days finish, the "Apply for production" button unlocks on your dashboard. Clicking it opens a mandatory questionnaire evaluated by human reviewers.
[The Production Access Questionnaire Pillars]
Question 1: Tester Recruitment Strategy ββ> Must prove hardware & network diversity
Question 2: Feedback & Bug Remediation ββ> Must cite specific fixes and versionCode 2+
Question 3: Production Readiness Criteria ββ> Must cite Android Vitals & Robo report proof
The 2-Build Rule:
To ace this questionnaire, you should deploy at least one updated App Bundle (versionCode 2) midway through your closed test. This provides concrete evidence that you listened to tester feedback, fixed bugs, and verified OTA updates before asking for public release.
For step-by-step questionnaire answers, see our closed testing checklist before applying for production.
Avoid Production Access Questionnaire Rejections
Don't gamble your launch on guesswork. AppConsoleLab provides verified physical device cohorts, active engagement telemetry, and expert questionnaire documentation.
Master Compliance Scorecard
Use this checklist to ensure every mandatory requirement is met before submitting your application:
| Requirement Area | Mandatory Condition | Verification Location | Status |
|---|---|---|---|
| Identity Verification | Government ID / D-U-N-S approved | Developer account > Account details | Mandatory |
| Target SDK | Target SDK 34 or 35 | Release > App bundle explorer | Mandatory |
| App Access | Functional test login credentials provided | App compliance > App access | Mandatory |
| Closed Testing | 12+ testers continuously enrolled for 14 days | Closed testing > Testers | Mandatory |
| Android Vitals | Crash rate < 1.09%, ANR rate < 0.47% | Quality > Android vitals | Mandatory |
| Data Safety | Disclosed all SDK data collection | App compliance > Data safety | Mandatory |
| Release Iteration | At least 2 builds tested (versionCode 1 & 2) | Closed testing > Releases | Essential |
| Console Feedback | 3 to 5 written reviews in Console | Closed testing > Feedback | Essential |
Guaranteed Production Access Testing Packages
If you want to ensure your closed testing track satisfies every single mandatory requirement with zero stress, explore AppConsoleLab's verified testing solutions:
One Cycle. Complete Approval.
Select the plan that fits your release complexity.
Loading Packages
Please wait while we fetch the best options for your region...
Frequently Asked Questions
What are all the mandatory requirements to get Google Play production access?
The mandatory requirements include: 1) Developer identity or organization D-U-N-S verification; 2) Meeting target SDK 34/35 requirements with an AAB; 3) Providing functional login credentials in App access; 4) Completing 14 continuous days of closed testing with at least 12 opted-in testers; 5) Keeping Android Vitals crash rates under 1.09%; 6) Complete Data Safety and Privacy Policy compliance; and 7) Passing the production access questionnaire review.
Do corporate developer accounts need 12 testers for 14 days?
No. The 12-tester, 14-day closed testing requirement applies specifically to personal developer accounts created after November 13, 2023. Organization accounts with verified D-U-N-S numbers are exempt from this mandatory closed testing requirement.
What happens if a tester uninstalls on Day 13 of closed testing?
If your active opted-in tester count drops below 12 on Day 13 and you have no backup testers enrolled, your 14-day countdown clock pauses or resets to Day 1 once you recruit a replacement. Recruiting 16 to 20 testers provides a safety buffer against this risk.
What is Google's bad behavior threshold for Android Vitals during closed testing?
Google enforces two core thresholds: a user-perceived crash rate exceeding 1.09% or an Application Not Responding (ANR) rate exceeding 0.47%. Exceeding these numbers over your 14-day test gives reviewers immediate technical grounds to reject production access.
Can I apply for production access immediately after the 14th day concludes?
Yes, once the 14 continuous days are marked complete in Play Console, the "Apply for production" button unlocks on your dashboard. You will then complete a detailed questionnaire detailing your tester recruitment, feedback collected, and bug fixes.
Unlock Your Production Access Today
Earning Google Play production access is a matter of preparation and compliance. By fulfilling every technical, regulatory, and testing standard across the 7 mandatory pillars, you eliminate review risks and set your app up for a smooth, successful launch on the Google Play Store.
Need 12 Active Testers for Google Play Production?
Ensure 100% compliance with Google Play requirements. Get 12+ real Android testers with active engagement telemetry and guaranteed approval.