Google Play gives you access to an estimated 3.5 billion Android users. But most first-time submissions get rejected — and the reason usually isn't your code.

It's a missing privacy policy link, an unjustified permission request, or a data safety declaration that doesn't match what your app actually does. Google blocked 2.36 million policy-violating apps in recent enforcement sweeps. The platform is getting stricter, not easier.

The solopreneurs who launch successfully treat submissions as compliance projects, not just technical uploads. They know that privacy policies must appear in two specific places, that new developer accounts require 14 days of closed testing with at least 12 real users, and that every sensitive permission requires written justification that reviewers will actually read.

This guide gives you the complete checklist, so you'll know precisely what Google checks—and how to be ready for it before you hit submit.

What Google actually checks

Google's review process combines automated scans with manual policy review. When you submit an app, it runs automated checks for malware, crashes, and policy violations before a human reviewer examines your store listing, permissions, and data-handling practices.

Google Play has become significantly stricter in recent years. Google has removed millions of apps to eliminate low-quality submissions, and new requirements for testing, identity verification, and data transparency have added friction that catches unprepared developers off guard.

None of the standard rejection triggers requires advanced technical skills to address. They require knowing what Google checks and preparing for it before you submit: account setup, privacy documentation, permissions, testing requirements, store listing preparation, and the submission process itself.

Setting up your developer account the right way

Before you can publish anything, you need a properly configured Google Play Developer account. The setup process includes decisions and verification steps that affect what you can publish and when.

Start by choosing between a Personal and an Organization account.

• Personal accounts are for individual developers, hobbyists, and sole proprietors — verification requires a government-issued ID.
• Organization accounts are for companies, LLCs, and partnerships and require business documentation such as articles of incorporation or a business license.

This choice matters because specific app categories (financial services, health apps, and VPNs) now require Organization accounts. Google's testing requirements documentation explains these account differences in detail.

The registration fee is $25, paid once. This fee permanently links your developer identity to your Google account, so make sure you're using the account you want associated with your apps long-term.

New personal accounts created after November 2023 face additional requirements before publishing, including closed testing with real users and device verification. These requirements are covered in detail in the testing section below.

Set up your payment information accurately from the start. Errors or inconsistencies between your payment details and identity verification can block your ability to publish. If you plan to sell paid apps or use in-app purchases, you'll also need to configure a merchant account, which has its own verification requirements.

Privacy policy and data safety — the #1 rejection trigger

Privacy documentation causes more rejections than any other issue. Google requires every app that collects or processes user data to have a published privacy policy. Since nearly every app collects some form of data (even basic analytics or crash reporting), this effectively means every app needs one.

Your privacy policy must explain what data your app collects, how you use that data, how users can request that their data be deleted, and how any third-party services (such as analytics providers or authentication systems) handle user information. The policy needs to be hosted on a working URL with no redirects, 404 errors, or access restrictions.

Here's where many developers make their first mistake: the privacy policy link must appear in two separate places.

1. In the App Content section of the Play Console, where you complete your data safety declarations.
2. In your store listing itself, visible to users browsing Google Play.

Missing either location can trigger rejection. Google's data safety documentation walks through exactly where each link needs to appear.

The data safety declaration is where things get more complex. Google requires you to answer detailed questions about the data your app collects, whether it is shared with third parties, and the security measures that protect it. The critical requirement is accuracy — your declarations must match what your app actually does.

Here's what typically trips people up: forgetting to declare analytics data collection.

If you use Firebase Analytics, Google Analytics, or similar services, you're collecting data whether you think of it that way or not. Crash reporting services that capture device information are another frequent omission. And many developers don't account for authentication providers that access user email addresses or profile information.

You'll also need a delete account URL if your app allows users to create accounts. This page allows users to request the deletion of their account and associated data. The URL must be accessible and functional — Google will check it during review. The User Data policy explains the specific requirements for account deletion.

The safest approach — and one that prevents most of these issues — is to audit your app's data practices before filling out any declarations. List every piece of information your app accesses, every third-party SDK you've integrated, and every service that touches user data. Then complete your data safety form based on that audit, not on what you think your app does.

Permissions — requesting only what you can justify

Google treats permission requests as a signal of respect for user privacy. Apps that request unnecessary permissions face additional scrutiny, and requests for sensitive permissions require written justification that reviewers will actually evaluate.

Here's what draws the most attention:

• Location access (both fine and coarse)
• Camera and microphone access
• Contacts and call log access
• SMS and phone state access
• Broad storage access

Each of these requires you to explain why your app's core functionality depends on this permission.

That said, the justification you provide matters more than the permission itself. Saying "we need a location for app functionality" isn't enough.

You need to explain specifically how location access serves the user — "Location is required to show nearby restaurants on the map," or "Location access enables accurate weather forecasts for the user's current city." The explanation should make clear that removing this permission would break a feature users expect the app to provide.

Before you submit, audit your permission requests against your actual feature set. For example, if you're requesting camera access but your app doesn't have any photo or video features, that's a red flag.

If you're requesting location access but only using it for analytics, Google will likely reject your request — location access for analytics alone isn't considered a valid justification.

The principle is simple: request only what your core functionality requires. Every additional permission is a potential rejection trigger and a reason for users to hesitate before installing your app.

Pre-launch testing and technical requirements

Google runs your app through automated testing on virtual devices as part of the review process. These pre-launch reports check for crashes, ANR (Application Not Responding) errors, and basic functionality issues. Apps that fail these tests get rejected. The best part? You can run the same tests yourself before submitting.

The 14-day closed testing requirement

New personal developer accounts created after November 2023 must complete a closed testing period before publishing to production.

You must recruit at least 12 real testers who are opted in to your closed test for a minimum of 14 continuous days. Google also requires you to verify access to a physical Android device using the Play Console mobile app.

These requirements exist because Google was dealing with a flood of low-quality and malicious apps published from anonymous, disposable accounts. The testing requirement forces you to prove your app works for real users before it goes public.

Start recruiting testers early. Friends and family work, but they need to genuinely engage with the app, not just install it and forget about it. Google can detect whether testers are actually using the app, so passive installations don't count toward your requirement.

Plan your launch timeline around this requirement. If you're setting up a new personal account, add at least three weeks to your schedule — two weeks for the testing period plus buffer time for recruiting testers and addressing any issues they discover.

App signing and Android App Bundles

Google requires all new apps to use Play App Signing and to be uploaded as Android App Bundles (AAB) rather than APKs. Play App Signing means Google manages your app's signing key, improving security and enabling features such as automatic optimization across different device configurations.

Android App Bundles let Google generate optimized APKs for each user's specific device, reducing download sizes. If you're using a platform that handles deployment for you, these requirements are typically managed automatically.

If you're working with developers or building manually, confirm that your build process produces AAB files and that Play App Signing is configured before your first submission.

Device and version testing

Test across multiple device types and Android versions, because an app that works perfectly on a Pixel running the latest Android might crash on a Samsung running an older version. The more diverse your testing, the fewer surprises you'll encounter during Google's review.

AI tools have made app development faster, enabling more people to experiment and build. But speed in development doesn't mean you can skip testing — it means you have more time to test thoroughly before launch. Use that time.

Store listing: what gets flagged and what converts

Your store listing serves two purposes: it convinces Google's reviewers that your app is complete and legitimate, and it convinces users to install. Placeholder content fails both tests.

Required elements include:

• App title (without keyword stuffing—Google penalizes titles that cram in search terms unnaturally)
• Short description of up to 80 characters
• Full description of up to 4,000 characters
• Screenshots for each device type you support
• Feature graphic
• App icon

Every element must be complete and accurate.

But completeness isn't enough—accuracy matters just as much. Your screenshots must represent actual app functionality; using mockups that show features your app doesn't have will get you rejected. Your descriptions must match what the app actually does. Any claims about functionality, whether in text or images, must reflect what users will actually experience when they download your app.

The content rating questionnaire asks about mature themes, violence, language, and other content categories. Answer honestly—if Google discovers your app contains content that doesn't match your declared rating (like content generated by AI features within your app, user-generated content, or anything users might encounter during normal use), they'll remove it.

What commonly causes delays:

• Screenshots from a different app or earlier version—anything that doesn't match current functionality
• Descriptions that promise features still in development
• Titles that violate trademark guidelines
• App icons that resemble existing popular apps too closely

Think of your store listing as a contract with users. Everything you show and say should be something you can deliver the moment they download your app.

Submission and review — what to expect

The submission process happens through the Google Play Console. Once you've completed all the required sections—app content, store listing, pricing and distribution—you can submit for review.

Review timing varies:

• Most reviews are complete within a few days
• New apps and apps in sensitive categories (health, finance, children's content) typically take longer
• Peak submission periods around holidays or major events can extend wait times
• Plan for at least a week between submission and expected availability, with buffer time if your launch date is fixed

If your app gets rejected, Google provides feedback explaining why. Read this carefully—it tells you exactly what to fix. The feedback typically references specific policy sections and identifies the problematic content or configuration. Fix the issues completely before resubmitting.

Avoid the rejection cycle. Multiple rapid rejections can escalate consequences. If you submit, get rejected, make a minimal change, submit again, get rejected again, and repeat this cycle, Google may flag your account for additional review or impose publishing restrictions. Take time to fully address rejection feedback rather than making quick fixes and hoping the next reviewer is more lenient.

If you believe a rejection was incorrect, you can appeal through the Play Console. Appeals go to human reviewers who will re-evaluate your app against the policies cited in your rejection. Provide clear documentation explaining why you believe your app complies.

Managed publishing gives you control over when approved apps go live. If you enable this feature, your app won't become available immediately after approval—you'll have the option to publish when you're ready. This is useful when coordinating launches with marketing campaigns or other timing requirements.

After approval — staying compliant long-term

Getting approved once doesn't mean you're done with compliance. Google regularly updates its policies and deadlines, and gives developers 30 days from announcement to adapt, although some changes have longer timelines.

Key ongoing compliance areas:

• API level requirements. Google requires apps to target recent Android versions, and this target level increases over time. As of August 31, 2025, new apps and updates must target Android 15 (API level 35) or higher, and must include API level documentation. If you're not updating your app regularly, it may no longer meet the minimum requirements and be removed from the store or hidden from devices running newer Android versions.
• Privacy policy and data safety declarations. Keep these current. If you add new features that collect additional data or integrate new third-party SDKs, update your declarations to match. Google can and does re-review published apps, and mismatches between your declarations and actual behavior can result in suspension.
• User reviews. Respond to negative ones, especially those that report bugs or crashes. High crash rates and poor ratings affect your app's visibility in search results and can trigger additional review from Google. Maintaining a rating above 4.0 stars significantly improves your discoverability and download conversion rates.

Update reviews are typically faster than initial submission reviews, but they still happen. Every update goes through the same compliance checks, so the same rules about permissions, data declarations, and content accuracy apply to every version you publish.

Your launch checklist

Successfully launching your app on Google Play comes down to treating submission as a compliance project, not just a final step after development. The builders who avoid rejection delays are the ones who prepare their documentation, declarations, and account setup before they ever hit submit.

Before you submit, confirm:

• The developer account is verified with accurate identity and payment information
• Privacy policy is published and linked in both required locations (App Content and store listing)
• Data safety declaration accurately reflects your app's actual data collection and handling
• The delete account URL is functional if your app allows account creation
• Permission requests are limited to what your core functionality requires, with written justifications
• App is uploaded as an Android App Bundle with Play App Signing configured
• Pre-launch testing shows no crashes or ANR errors
• 14-day closed testing requirement with 12+ testers is complete (for new personal accounts)
• Store listing is complete with accurate screenshots, descriptions, and content ratings
• All claims in your listing match actual app functionality

The opportunity is real: 3.5 billion Android users and a submission process that rewards preparation over technical sophistication.

Start with the checklist above. Work through each item before you open the Play Console to submit — fixing compliance issues before review is faster than fixing them after rejection. Once you've launched successfully, the same habits apply to every update, reducing friction as you iterate based on what your users actually need.

If you're building your app with Anything, Android deployment and app signing are handled automatically, so you can focus on preparing for compliance to launch your app on Google Play successfully.