Gplay Submission Checks

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 validate \
    --package com.example.app \
    --bundle app-release.aab \
    --track production \
    --strict

• `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.

  gplay preflight --file app-release.aab --max-size 150M --fail-on warning

  # Validate the store listing in the same pass
  gplay preflight --file app-release.aab --listings-dir ./metadata --fail-on error

  # Narrow the gate
  gplay preflight --file app-release.aab --only manifest,permissions,native_libs

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 checks upload \
    --account "$CHECKS_ACCOUNT" \
    --app "$CHECKS_APP" \
    --binary app-release.aab \
    --binary-type ANDROID_AAB \
    --severity-threshold PRIORITY

• `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.

  gplay publish track \
    --package com.example.app \
    --track production \
    --bundle app-release.aab \
    --release-notes @release-notes.json \
    --strict

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

gplay validate bundle --file app-release.aab

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:

gplay validate bundle --file app-release.apk

2. Validate Store Listing Metadata

gplay validate listing --dir ./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:

gplay validate listing --dir ./metadata --locale en-US

For JSON format metadata:

gplay validate listing --dir ./metadata --format json

3. Validate Screenshots

gplay validate screenshots --dir ./metadata

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:

gplay validate screenshots --dir ./metadata --locale en-US

4. Verify Existing Listings on Play Store

Compare local metadata against what is live:

gplay sync diff-listings \
  --package com.example.app \
  --dir ./metadata

Check all configured locales:

EDIT_ID=$(gplay edits create --package com.example.app | jq -r '.id')
gplay listings list --package com.example.app --edit $EDIT_ID --output table

5. Data Safety Declaration

Ensure the data safety form is complete. Missing or inaccurate data safety declarations are a common rejection reason.

gplay data-safety update \
  --package com.example.app \
  --json @data-safety.json

6. Version Code Check

The version code must be strictly higher than all previous releases on every track. Check current track status:

gplay tracks list --package com.example.app --output table

Get details for a specific track:

EDIT_ID=$(gplay edits create --package com.example.app | jq -r '.id')
gplay tracks get --package com.example.app --edit $EDIT_ID --track production --output table

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:

EDIT_ID=$(gplay edits create --package com.example.app | jq -r '.id')
gplay deobfuscation upload \
  --package com.example.app \
  --edit $EDIT_ID \
  --apk-version 42 \
  --file mapping.txt
gplay edits commit --package com.example.app --edit $EDIT_ID

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:

gplay release \
  --package com.example.app \
  --track production \
  --bundle app-release.aab \
  --release-notes @release-notes.json \
  --dry-run

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:

EDIT_ID=$(gplay edits create --package com.example.app | jq -r '.id')

# ... upload bundle, update tracks, etc. ...

# Validate the edit (catches all server-side issues)
gplay edits validate --package com.example.app --edit $EDIT_ID

# Only commit if validation passes
gplay edits commit --package com.example.app --edit $EDIT_ID

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:

# The policy scanner reports targetSdkVersion against Play's floor
gplay preflight --file app-release.aab --only policy

# Override the floor if Google's annual bump landed before a gplay release
gplay preflight --file app-release.aab --only policy --min-target-sdk 36

Fix it in build.gradle / build.gradle.kts:

android {
    defaultConfig {
        targetSdk = 35  // set to Play's current floor or higher
    }
}

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)