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 in Play 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:

  1. You must select "All or some functionality is restricted".
  2. Provide a working demo username and password (e.g., google-tester@yourdomain.com).
  3. 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.
  4. 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.

Money-back compliance guarantee

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:

  1. Check Play Console > Quality > Android vitals > Crashes and ANRs on Days 3, 7, and 12.
  2. Fix all background exceptions, out-of-memory errors, and main-thread I/O operations.
  3. 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 RequirementWhat Google RequiresCommon Rejection Trap
Privacy PolicyLive, publicly accessible URL detailing data collectionDead link, 404 error, or generic generator text
Data SafetyAccurate disclosure of collected data types (Location, Photos, Device IDs)Failing to disclose third-party SDK data (e.g. AdMob/Firebase)
Target AudienceDeclaring whether your app targets children under 13Claiming "Not for children" when the app uses cartoon graphics
Financial / HealthSpecial declarations if handling medical data or loansMissing 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.

Money-back compliance guarantee

Master Compliance Scorecard

Use this checklist to ensure every mandatory requirement is met before submitting your application:

Requirement AreaMandatory ConditionVerification LocationStatus
Identity VerificationGovernment ID / D-U-N-S approvedDeveloper account > Account detailsMandatory
Target SDKTarget SDK 34 or 35Release > App bundle explorerMandatory
App AccessFunctional test login credentials providedApp compliance > App accessMandatory
Closed Testing12+ testers continuously enrolled for 14 daysClosed testing > TestersMandatory
Android VitalsCrash rate < 1.09%, ANR rate < 0.47%Quality > Android vitalsMandatory
Data SafetyDisclosed all SDK data collectionApp compliance > Data safetyMandatory
Release IterationAt least 2 builds tested (versionCode 1 & 2)Closed testing > ReleasesEssential
Console Feedback3 to 5 written reviews in ConsoleClosed testing > FeedbackEssential

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.

Money-back compliance guarantee

Stuck in Closed Testing? We provide the 12 real testers you need for 14 days.

Get 12 Testers Now!
Google Play Production Access Requirements: All Mandatory Requirements Explained