Pre-submission validation for Google Play releases covering metadata, screenshots, bundle integrity, data safety, and policy compliance. Use when preparing a release to avoid rejections and catch issues before submitting.

Google Play Submission Checks Use this skill to validate everything before submitting a release to Google Play, reducing rejections and failed edits. Preconditions Auth configured ( gplay auth login or GPLAY SERVICE ACCOUNT env var). Package name known ( package or GPLAY PACKAGE ). AAB/APK built and signed. Service account has at least "Release Manager" permission. Prefer the First Class Commands The CLI has canonical, purpose built commands. Reach for these before hand scripting individual validators: gplay validate package <pkg — the canonical release readiness report. Combines local artifact/metadata/screenshot/release note checks with remote track and listing state and Console only follow up items. Use bundle , listings dir , screenshots dir , track , and strict (treat warnings as failures) to scope it. gplay preflight file <app.aab — offline AAB/APK compliance and hygiene. Fully decodes AndroidManifest.xml (binary AXML for APKs, aapt2 protobuf for App Bundles) and runs nine scanners: manifest , permissions , native libs , metadata , secrets , billing , privacy , policy , size . No API calls and no credentials. Exit codes: 0 clean, 1 findings at/above fail on . See the gplay preflight skill for what each scanner catches, how to read the findings, and CI gating patterns. gplay checks upload — Google Checks compliance analysis as a CI gate. Use severity threshold PRIORITY to fail the pipeline on high priority failed checks before release. gplay publish track strict — preflight + publish in one step. Builds the readiness report, stops on blocking issues (and warnings with strict ), then runs the release workflow only if preflight passes. The detailed per artifact checks below remain useful for narrowing down a failure or for CI steps that gate on one concern at a time. Pre submission Checklist 1. Validate Bundle Integrity Checks: File exists and is readable File has .aab extension Valid ZIP archive structure Contains required bundle components (manifest, resources, dex) If using APK instead: 2. Validate Store Listing Metadata Checks: Title : max 30 characters Short description : max 80 characters Full description : max 4000 characters Required fields present Valid UTF 8 encoding Validate a specific locale: For JSON format metadata: 3. Validate Screenshots Checks: Minimum 2 screenshots per device type Maximum 8 screenshots per device type Valid image formats (PNG, JPEG) Files are readable Validate for a specific locale: 4. Verify Existing Listings on Play Store Compare local metadata against what is live: Check all configured locales: 5. Data Safety Declaration Ensure the data safety form is complete. Missing or inaccurate data safety declarations are a common rejection reason. 6. Version Code Check The version code must be strictly higher than all previous releases on every track. Check current track status: Get details for a specific track: 7. Deobfuscation / Mapping File Upload ProGuard/R8 mapping files so crash reports in Play Console are readable. This command is edit scoped (needs edit ) and the version flag is apk version , not version code : Without mapping files, crash stack traces in Android Vitals will be obfuscated and unusable. 8. Dry Run the Release The safest pre submission check. Performs the full release pipeline without committing: This will: Create an edit Upload the bundle Configure the track Validate the edit (catches API level errors) Discard the edit without committing If the dry run succeeds, the real release will succeed. 9. Edit Validation (Manual Sequence) When using the manual edit workflow, always validate before committing: Content Policy Compliance Target API Level Google Play requires apps to target a recent Android API level, and raises the floor roughly every August to "latest release minus one". Both new apps and updates are affected; builds below the floor are rejected at upload. Check the build without guessing at the current number: Fix it in build.gradle / build.gradle.kts : Do not tell the user a specific required API level from memory — read it from the policy scanner output or from Play's published requirement. Permissions Declarations Sensitive permissions require justification in the Play Console: ACCESS FINE LOCATION / ACCESS BACKGROUND LOCATION READ CONTACTS , READ CALL LOG , READ SMS CAMERA , RECORD AUDIO REQUEST INSTALL PACKAGES QUERY ALL PACKAGES Remove any permissions your app does not actually need. Unused sensitive permissions are a top rejection reason. Data Safety Form All apps must have a complete data safety section. Common data types to declare: Personal info (name, email, phone) Location (approximate, precise) Financial info (purchase history) App activity (in app search, other user generated content) Device identifiers (advertising ID) App Content Ratings Ensure your content rating questionnaire is completed in Play Console. Missing ratings block distribution. Screenshot Requirements by Device Type Device Type Image Type Min Max Min Resolution Phone phoneScreenshots 2 8 320px (min side) 7 inch Tablet sevenInchScreenshots 0 8 320px (min side) 10 inch Tablet tenInchScreenshots 0 8 320px (min side) Android TV tvScreenshots 0 8 1280x720 Wear OS wearScreenshots 0 8 320px (min side) Additional image assets: Asset Type Required Feature Graphic featureGraphic Yes (for featuring) Promo Graphic promoGraphic No Icon icon Set via Play Console TV Banner tvBanner Required for TV apps Common Rejection Reasons and Fixes 1. "Version code already exists" Cause : The version code in your bundle matches an existing release. Fix : Increment versionCode in build.gradle and rebuild. 2. "APK/Bundle targets an SDK below the required level" Cause : targetSdkVersion is too low. Fix : Update targetSdkVersion to 34 or higher and rebuild. 3. "Data safety form incomplete" Cause : The data safety declaration is missing or incomplete. Fix : Complete the data safety form in Play Console or update via CLI: 4. "Screenshots missing for required device type" Cause : Phone screenshots are required for all apps. Fix : Add at least 2 phone screenshots: 5. "Release notes missing for default locale" Cause : No "What's New" text for the default language. Fix : Include release notes in the release command: 6. "Signing key mismatch" Cause : The bundle is signed with a different key than what Play Console expects. Fix : Use the same upload key configured in Play App Signing. Check your keystore configuration. 7. "Deobfuscation file too large" Cause : Mapping file exceeds 300 MB limit. Fix : Strip unused mappings or compress the file. Pre launch Report Google Play runs automated tests on your app before review (pre launch report). Common issues surfaced: Crashes on launch : App crashes on one or more test devices Security vulnerabilities : Known CVEs in dependencies Accessibility issues : Missing content descriptions, small touch targets Performance warnings : Slow startup, excessive wake locks Check pre launch reports in Play Console after uploading to any track. Address critical issues before promoting to production. Full Pre submission Pipeline CI/CD Integration Add these checks to your CI pipeline to catch issues before they reach Play Console: Agent Behavior Prefer the first class commands: gplay validate (readiness report), gplay preflight (offline), gplay checks upload (Checks gate), and gplay publish track strict (preflight + publish) over hand scripting. Always run gplay validate before attempting a release. Use dry run (or publish track strict ) as the final gate before real releases. gplay deobfuscation upload is edit scoped: use edit and apk version (not version code ), then commit the edit. Always confirm exact flags with help before running commands. Use output table for human readable validation output. When multiple validation steps fail, report all failures together rather than stopping at the first one. Check version code conflicts by listing tracks before releasing. Remind the user about data safety declarations if they have not mentioned them. Notes gplay validate commands run locally and do not require API calls. gplay release dry run creates a real edit session but discards it after validation. gplay edits validate is the server side equivalent, catching issues that local validation cannot. Always use help to verify flags for the exact command. Use output table for human readable output; default is JSON.

gplay-submission-checks