App rejected due to an incorrectly declared MANAGE_EXTERNAL_STORAGE permission? Or automated check flagged your build because of an outdated targetSdkVersion? This happens on every second release if you don't prepare in advance. We help you pass Google Play review on the first attempt, without iterations.
Google Play uses a two-tier review: automated scripts and human reviewers for apps that trigger certain flags. The first line scans the manifest, code, used APIs, and dependencies. The second checks compliance with the Family Policy, Accessibility Service usage, and justification of sensitive permissions. Our team conducts a pre-audit using a checklist of 30+ items to eliminate all possible rejection reasons.
We work with any stack: from Flutter and React Native to native Kotlin apps. Experience: 10+ years in mobile development, over 200 successful publications. With us, you get a review pass guarantee or fixes at our expense.
How to prepare your app for Google Play review?
Play Protect scans APK/AAB for non-standard API usage, reflection to bypass restrictions, suspicious network requests. If the project includes an SDK with known issues, a flag appears immediately. Most often, problems are caused by outdated ad SDKs (AdMob below a certain version, old Unity Ads) and some analytics libraries with aggressive data collection.
targetSdkVersion must meet current Google requirements. For new apps, the minimum is API 34 (Android 14). An app with targetSdkVersion below the requirement will not pass publication at all — it's a hard block.
The Data Safety section is automatically checked for gross discrepancies: if code explicitly uses AdvertisingIdClient to retrieve GAID, but Data Safety declares "we do not collect device identifiers" — the algorithm catches it. According to Google Play policy, inconsistency is one of the main reasons for rejection.
| Reason | Symptoms | Solution |
|---|---|---|
| Outdated targetSdkVersion | Hard block on upload | Update targetSdkVersion to 34+ |
| Data Safety mismatch | Algorithm detects inconsistency | Verify declaration, use Privacy Sandbox |
| Sensitive permission | Reject from reviewer | Justify, replace with MediaStore |
| Accessibility Service misuse | Rejection with comment | Remove or declare accurately |
| Non-certified ad SDK for family | Instant reject | Replace with certified SDK |
Tip: Check ProGuard/R8 rules. Often a rejection occurs due to obfuscated code that uses reflection. Ensure keep rules cover all classes called via reflection.
Why do reviewers reject apps?
Sensitive permissions without sufficient justification. MANAGE_EXTERNAL_STORAGE is one of the toughest permissions. Google approves it only for file managers, antiviruses, and backup apps. Attempting to use it for "convenient file saving" gets rejected. Alternative: MediaStore API + ACTION_CREATE_DOCUMENT.
Misuse of Accessibility Service. Google explicitly prohibits using AccessibilityService for analytics, auto-clickers, or tracking user actions outside declared use case. Declaration must precisely describe the purpose.
Violation of family app policy. If any target age includes "children", all ad SDKs must be certified for children's audience. An uncertified ad SDK connected — instant reject.
Comparison: automated reject is faster, but manual is more thorough — in 70% of cases, rejection is due to Data Safety inconsistency, which can be fixed in 1 day. Official documentation confirms the importance of proper setup.
What technical requirements must be met before publication?
Publish only AAB (Android App Bundle), not APK — since 2021 it's mandatory for new apps. Signature: keystore must match the one registered in Play App Signing. If signing through Google Play App Signing, upload key and signing key are different entities; confusion here is costly if the key is lost.
versionCode must be greater than the previously published one. Sounds obvious, but conflicts happen in CI with multiple developers working in parallel.
Our work process
Check AndroidManifest.xml, build.gradle, Data Safety section in Play Console. Build a release AAB with signature. Upload to Internal Testing, basic testing. Move to Production track with gradual rollout (usually start at 10-20%). Monitor ANR/crash rate in Android Vitals during the first 48 hours after release.
| Stage | Duration | Responsible |
|---|---|---|
| Code and manifest audit | 1-2 days | Our engineer |
| Fixing issues | from 1 day | Depends on complexity |
| Build AAB and sign | 1 day | CI/CD |
| Publish to Internal Testing | 1 day | Play Console |
| Production rollout | 2-3 days | Gradual 10-20% |
What is included in the work
- Full audit of manifest, gradle files, and Data Safety section
- Fixing all issues, including updating targetSdkVersion, permissions, and policies
- Setting up signature and building a release AAB
- Upload to Internal Testing and preparation for Production
- Filling out Data Safety form in Play Console
- Responding to reviewer comments (if necessary)
- Error monitoring for 48 hours after publication
Timeline and cost
Average time from start to publication: 3 to 7 business days, depending on project complexity and number of issues. Cost is calculated individually and includes all stages described above. We guarantee passing the review or fix problems at our expense.
Our experience and guarantees
10+ years in mobile development, over 200 successful releases on Google Play. Certified Android and Flutter specialists. We provide a written guarantee for passing moderation. Contact us for a free assessment of your project. Get a consultation right now.