Figure 1: The intersection of app development, encryption security, and global export compliance.
Introduction to Export Compliance
Every Android developer publishing on Google Play must navigate export compliance and encryption declarations before their app reaches users. These requirements, rooted in U.S. export control law, govern how software that contains encryption can be distributed internationally. Combined with Google Play's closed testing requirement for new personal developer accounts, understanding these rules is essential to a smooth launch.
Historically, export controls on encryption were designed to prevent adversaries from accessing technologies that could compromise national security. Today, however, encryption is ubiquitous—used in everything from checking email to streaming video. The U.S. government has adapted its regulations to allow widespread use of consumer encryption, but the paperwork remains a mandatory step.
This guide explains what encryption declarations are, why they exist, how they intersect with Google Play's closed testing policy, and how to complete them quickly without derailing your release timeline.
What Is an Encryption Declaration?
An encryption declaration is a formal statement submitted through the Google Play Console that confirms whether your application uses encryption and, if it does, whether it qualifies for export under U.S. law. The declaration is required for every app published on the Play Store, including those distributed only to closed testing tracks.
Google collects this information because the company, headquartered in the United States, is legally obligated to comply with the Export Administration Regulations (EAR) administered by the Bureau of Industry and Security (BIS), a division of the U.S. Department of Commerce.
The declaration covers several key areas:
- Whether encryption is used in your app, including third-party libraries
- The type of encryption — symmetric, asymmetric, hashing, or transport-layer
- The purpose — data at rest, data in transit, authentication, digital rights management
- Whether the app qualifies for the mass market exemption
- Whether a CCATS (Commodity Classification Automated Tracking System) number has been issued
Why Encryption Compliance Matters
Encryption is considered a "dual-use" technology — it has both civilian and potential military applications. As a result, the U.S. government restricts the export of encryption software to certain countries, entities, and end-users. Failing to comply with these restrictions can result in:
- App rejection or removal from Google Play
- Suspension of your developer account
- Significant civil penalties — up to $300,000 per violation or twice the value of the transaction
- Criminal charges in cases of willful violation
- Being placed on the Denied Persons List
For most developers, the practical impact is simpler: without completing the encryption declaration, your app cannot be published to any track, including internal, closed, or open testing. This directly blocks the closed testing phase required for personal accounts created after November 2023.
Figure 2: Without a completed encryption declaration, your app rollout is entirely blocked.
The Export Administration Regulations (EAR) Explained
The EAR classifies encryption items under Export Control Classification Number (ECCN) 5D002, which covers software that uses cryptography for confidentiality. Items classified under 5D002 are subject to strict export controls unless they qualify for an exemption.
Key concepts every Android developer should understand:
1. "Export" Is Broader Than You Think
Under U.S. law, an "export" is not just shipping software overseas. It includes:
- Making software available for download outside the United States
- Sharing source code with non-U.S. persons, even within the U.S.
- Providing technical assistance to non-U.S. persons
2. Encryption Includes Standard Protocols
Many developers assume encryption declarations only apply to apps with custom cryptography. In reality, any use of the following triggers the requirement:
- HTTPS / TLS / SSL
- VPN functionality
- Encrypted local storage (SQLCipher, EncryptedSharedPreferences)
- JWT token signing
- OAuth flows
- Code signing
- DRM for media content
3. Some Countries Are Restricted
Even with a valid encryption declaration, distribution is restricted or prohibited to certain countries, including those under comprehensive U.S. sanctions such as Cuba, Iran, North Korea, Syria, and the Crimea region. Google Play automatically enforces these geographic restrictions.
The Mass Market Exemption
The good news for most Android developers is that Note 4 to Category 5, Part 2 of the EAR provides a "mass market" exemption. Software that meets the following criteria is reclassified as EAR99 — meaning it can be exported without a license to most destinations:
- The encryption is widely available (e.g., open-source libraries like OpenSSL, BoringSSL, Conscrypt)
- The app is sold or freely distributed to the general public through standard retail channels like Google Play
- The user cannot easily modify the encryption functionality
- The app is designed for general consumer or business use, not customized for government or military applications
If your app qualifies — and the vast majority of consumer apps do — you simply check the appropriate box in the Play Console declaration. No formal classification request is needed, and there is no waiting period.
Google Play Encryption Requirements
Google Play enforces encryption compliance through the App content section of the Play Console. The specific form is titled "Export compliance" and includes the following questions:
- Does your app use encryption? — Answer "Yes" if your app uses any form of encryption, including HTTPS.
- Is your encryption exempt from U.S. export classification? — Most consumer apps answer "Yes" because they qualify for the mass market exemption.
- Do you have a CCATS number? — If your app has previously been classified by BIS, enter the number. Otherwise, leave blank.
Until these questions are answered, Google Play blocks the rollout of your app to every track. This means encryption declaration is a prerequisite for closed testing, which is itself a prerequisite for production access on personal developer accounts created after November 2023.
Figure 3: A stylized representation of the Export Compliance form in the Google Play Console.
Closed Testing and Compliance
Google Play closed testing is now mandatory for most new personal developer accounts. The rules require at least 12 testers for 14 consecutive days before production access can be requested. This testing period must occur on the Closed testing track — not internal testing — and the testers must be real users who install the app from the Play Store via an opt-in link.
Google instituted this requirement to reduce spam and low-quality apps on the Play Store. By forcing new developers to prove their app functions correctly for real users before broad distribution, Google aims to weed out malware clones, broken apps, and policy-evasion attempts.
Here's how encryption compliance intersects with closed testing:
- Step 1: Complete the encryption declaration in App content
- Step 2: Upload your app bundle to the Closed testing track
- Step 3: Generate your opt-in URL
- Step 4: Recruit 12–15 reliable testers
- Step 5: Monitor tester activity for 14 consecutive days
- Step 6: Apply for production access
Skipping the encryption declaration at any point halts the entire process. Many developers learn this only after their first attempted rollout is rejected — wasting days or weeks of preparation.
Figure 4: The mandatory 14-day continuous closed testing timeline for new developers.
Step-by-Step Compliance Process
1. Audit Your App's Encryption Usage
Before filling out the declaration, review your app's dependencies. Common encryption sources include:
- OkHttp, Retrofit, Volley (HTTPS networking)
- AndroidX Security library (EncryptedSharedPreferences, EncryptedFile)
- SQLCipher
- Firebase, AWS, Google Cloud SDKs (all use HTTPS)
- JWT libraries like jjwt or Nimbus JOSE
- Biometric APIs
If your app communicates with any remote server — and nearly every modern app does — you are using encryption. You can audit your dependencies by running a quick scan in your build.gradle files or using dependency analysis tools in Android Studio.
2. Complete the Declaration in Play Console
Navigate to your app in the Play Console, then go to Publishing overview → App content → Export compliance. Answer the questions truthfully:
- "Does your app use encryption?" → Yes (for 99% of apps)
- "Is it exempt from classification?" → Yes, if it qualifies for the mass market exemption
- "CCATS number?" → Leave blank unless previously classified
3. Upload to the Closed Testing Track
With the declaration complete, navigate to Release → Testing → Closed testing. Create a new release, upload your signed app bundle or APK, and complete the release notes. Google will review the submission (usually within 1-2 days) before making it available to your testers.
4. Generate Your Opt-In URL
Under the Testers tab of your closed testing release, create an email list of testers (or use a Google Group). Once saved, Google generates a unique opt-in URL that testers use to join your testing program.
5. Recruit 12–15 Reliable Testers
This is the most time-consuming step. Testers must:
- Be real human users with active Google accounts
- Accept the opt-in invitation
- Install the app from the Play Store (not sideloaded)
- Remain enrolled for the full 14-day window
Skip the Recruitment Hassle
Fast Testers assigns 15 professional Android testers within one hour for a one-time $15 fee — no subscription, no recruitment hassle. Get your closed testing done right the first time.
Start Closed Testing →6. Monitor the 14-Day Window
Each day, verify that at least 12 testers remain enrolled and that the app has been installed. If a tester drops out, recruit a replacement immediately to maintain the minimum count. Google’s dashboard updates daily, but there is sometimes a 24-hour delay in recognizing installs.
7. Request Production Access
After 14 consecutive days of compliant testing, return to the Play Console and submit a production access request. Include a summary of your testing results and confirm that your app meets all policy requirements.
Common Mistakes to Avoid
Mistake 1: Skipping the Encryption Declaration
The single most common error. Without the declaration, your closed testing rollout is blocked, and you may waste days wondering why the "Review release" button is greyed out.
Mistake 2: Using Internal Testing Instead of Closed Testing
Internal testing does not count toward the 14-day production access requirement. Only the Closed testing track qualifies. Internal testing is designed for immediate feedback from your own team, while closed testing simulates a real-world release environment.
Mistake 3: Sharing APK Files
Distributing APK files via email or download links does not count as a Play Store install. Testers must install through the opt-in URL from the Play Store. If Google detects sideloaded APKs masquerading as official installs, your production access request will be denied.
Mistake 4: Dropping Below 12 Testers
If your tester count falls below 12 on any day during the 14-day window, the counter may reset. Always maintain a buffer of 3–5 extra testers to account for uninstalls or inactivity.
Mistake 5: Requesting Production Access Too Early
Wait until the full 14 days have elapsed. Submitting a production access request on day 13 will be rejected, and you'll need to start over or wait additional days, delaying your launch even further.
Mistake 6: Using Emulator Installs or Install Farms
Google actively detects emulator-based installs, virtual devices, and install farms. These do not count and may flag your account for permanent suspension. Google’s anti-abuse algorithms look for patterns like identical device fingerprints, rapid sequential installs, and unrealistic geographical clustering.
Mistake 7: Incorrectly Answering "No" to Encryption
Some developers mistakenly answer "No" to the encryption question, believing HTTPS doesn't count. This is incorrect and can lead to compliance issues later. If your app makes any network request over HTTPS, you are using encryption.
When You Need a CCATS
A Commodity Classification Automated Tracking System (CCATS) number is required when your app does not qualify for the mass market exemption. This typically applies to:
- Apps with custom cryptographic algorithms not based on published standards
- Apps designed specifically for government or military use
- Apps that allow end users to easily modify or replace the encryption functionality
- Apps that implement "cryptographic activation" features that can be unlocked
- Apps used for infrastructure-level network encryption (e.g., VPN services with non-standard protocols)
If your app falls into any of these categories, you must submit a classification request to BIS through the SNAP-R system. The review process typically takes 2–4 weeks, though complex cases can take longer.
Once you receive a CCATS number, enter it in the Play Console encryption declaration. The number remains valid for that specific app version's classification.
Frequently Asked Questions
How fast do testers start with Fast Testers?
Typically within one hour after you submit your closed testing link. You'll receive a dashboard to track tester activity throughout the 14-day period.
Is using Fast Testers against Google policy?
No. Google explicitly supports closed testing with invited external testers. Fast Testers provides real human testers with genuine Google accounts who install your app through the official Play Store opt-in flow. We do not use bots, emulators, or install farms.
Do I need to redo the encryption declaration for every update?
No. The declaration is app-level, not release-level. You only need to update it if your app's encryption functionality materially changes — for example, if you add VPN features or custom cryptography in a future version.
What if my app is rejected for policy reasons after testing?
Fix the policy issues and resubmit. Your completed 14-day testing period still counts toward the requirement, so you won't need to re-run closed testing unless the app is significantly changed.
Does open-source encryption count?
Yes, but open-source encryption generally qualifies for the mass market exemption. Source code that is publicly available and already subject to public posting requirements under §742.15(b) of the EAR may be exported without a license.
What happens if I falsely claim my app doesn't use encryption?
False declarations can result in account suspension, app removal, and legal liability under U.S. export control law. Always answer truthfully — the mass market exemption makes compliance straightforward for the vast majority of apps.
Can I distribute my app outside Google Play to avoid the declaration?
The encryption declaration is specific to Google Play. However, U.S. export control law still applies to distribution through other channels. Sideloaded APKs, alternative app stores, and direct downloads are all subject to the EAR if distributed from the United States or by U.S. persons.
Do I need a CCATS for standard HTTPS requests?
No. Standard HTTPS, TLS, and SSL network requests using widely available, unmodified libraries (like OkHttp or Conscrypt) fall squarely within the mass market exemption. You do not need a CCATS for standard networking protocols.
Get Started with Fast Testers
Completing your encryption declaration is just the first step. The 14-day closed testing requirement is where most developers lose time. Fast Testers eliminates the recruitment bottleneck with a simple, one-time service:
- $15 per app — no subscription, no hidden fees
- 15 professional Android testers assigned within one hour
- Dashboard tracking with daily install verification
- Detailed reports for your production access application
- 99.9% success rate across 1,500+ published apps
Ready to pass Google Play closed testing effortlessly?
Start Closed Testing →