Passing Google Play Review for Publishing
Google Play Review works differently than App Store: first line is automatic checks, second line is live reviewer for flagged apps. It's faster, but errors in manifest or data policies cause instant rejection without explanation. We manage the entire publication — from final build to "Published" status.
What Blocks Automatically
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, the problem is created by outdated ad SDK versions (AdMob below a certain version, old Unity Ads versions) and some analytics libraries with aggressive data collection.
targetSdkVersion must match current Google requirements. As of 2025 for new apps, the minimum is API 34 (Android 14). An app with targetSdkVersion below required won't be published at all — this is a hard block.
Data Safety section is checked automatically for gross mismatches: if code explicitly uses AdvertisingIdClient to get GAID but Data Safety declares "we don't collect device identifiers" — the algorithm will catch it.
Typical Rejection Reasons from Reviewers
Sensitive permissions without sufficient justification. MANAGE_EXTERNAL_STORAGE — one of the most complex permissions. Google approves it only for file managers, antivirus, and backup apps. Attempting to use it for "convenient file saving" will be rejected. Alternative — MediaStore API + ACTION_CREATE_DOCUMENT.
Accessibility Service misuse. Google directly forbids using AccessibilityService for analytics, autoclickers, or tracking user actions outside the declared use case. Declaration must precisely describe the purpose.
Family policy violation. If even one target age group is "children", all advertising SDKs must be certified for child audience. Connected uncertified ad SDK — instant reject.
Technical Points Before Submission
Publish only AAB (Android App Bundle), not APK — mandatory for new apps since 2021. Signature — keystore must match the registered one in Play App Signing. If signing through Google Play App Signing, upload key and signing key are different entities; confusion here is costly when losing a key.
versionCode must be greater than the last published. Sounds obvious, but with parallel developer work in CI, conflicts happen.
Work Process
Verification of AndroidManifest.xml, build.gradle, Data Safety section in Play Console. Building release AAB with signature. Upload to Internal Testing, basic testing. Transition to Production track with gradual rollout (usually starting with 10-20%). Monitor ANR/crash rate in Android Vitals for first 48 hours after release.
Timeline from submission to publication: from several hours to two business days.