gpd is the Google Play Developer CLI used to manage publish flows, including preflight checks, listing validation, and release actions.

What should I do if the release is not in a valid state?

Verify that the versionCode is uploaded and attached to the track, ensure edit validation passes, and confirm required store listing fields are present for all locales before reattempting submission.

Do I need to upload a deobfuscation mapping?

Upload deobfuscation mappings if your app uses ProGuard/R8 and you need proper stack traces; use this step only when required by the release validation.

gpd-submission-health

Scanned

npx machina-cli add skill rudrankriyam/app-store-connect-cli-skills/gpd-submission-health --openclaw

Files (1)

SKILL.md

2.2 KB

GPD Submission Health

Use this skill to reduce Play Console submission failures and validate readiness.

Preconditions

Auth configured and package name resolved.
Build uploaded and available for the target track.
Store listing metadata and assets updated.

Pre-submission checklist

1. Validate edit (if using edit lifecycle)

gpd publish edit validate EDIT_ID --package com.example.app

2. Confirm release status

gpd publish status --package com.example.app --track production

Check:

Release status is expected (draft, inProgress, or completed).
Version code matches the uploaded build.

3. Verify store listing metadata

gpd publish listing get --package com.example.app
gpd publish details get --package com.example.app

4. Verify screenshots and assets

gpd publish images list phoneScreenshots --package com.example.app --locale en-US
gpd publish assets spec

5. Upload deobfuscation mapping (if needed)

gpd publish deobfuscation upload mapping.txt --package com.example.app --type proguard --version-code 123

Submit to production

gpd publish release --package com.example.app --track production --status inProgress --version-code 123

Common submission issues

Release not in valid state

Check:

Version code uploaded and attached to the track.
Edit validation passes.
Required store listing fields present for all locales.

Missing screenshots or assets

Use:

gpd publish images list phoneScreenshots --package com.example.app --locale en-US
gpd publish images upload icon icon.png --package com.example.app --locale en-US

Policy declarations not complete

Some policy/compliance items must be completed in Play Console UI. Confirm in the console if CLI operations pass but submission is blocked.

Notes

Use gpd publish edit validate before committing large changes.
Use --dry-run where available before destructive actions.

Source

git clone https://github.com/rudrankriyam/app-store-connect-cli-skills/blob/main/skills/gpd-submission-health/SKILL.mdView on GitHub

Overview

GPD Submission Health helps you preflight Google Play Console submissions to reduce failures. It guides you through validating edits, confirming release readiness, and ensuring listing metadata and assets are complete before shipping to production.

How This Skill Works

The skill runs a sequence of gpd commands to verify readiness: validate edits if using the edit lifecycle, check the production release status, and confirm that store listing metadata and media assets are complete. If needed, it can upload deobfuscation mappings before final submission to production.

When to Use It

Shipping a production release after updates to store listing or assets
Troubleshooting a failed or blocked production release
Validating edit lifecycle before committing large changes
Ensuring all required listing fields are present for all locales before release
Diagnosing issues where the version code does not match the uploaded build

Quick Start

Step 1: Validate edits and check status gpd publish edit validate EDIT_ID --package com.example.app gpd publish status --package com.example.app --track production
Step 2: Verify listing and media readiness gpd publish listing get --package com.example.app gpd publish details get --package com.example.app gpd publish images list phoneScreenshots --package com.example.app --locale en-US gpd publish assets spec
Step 3: Submit to production gpd publish release --package com.example.app --track production --status inProgress --version-code 123

Best Practices

Ensure auth is configured and the package name is resolved
Confirm the build is uploaded and available for the target track
Update store listing metadata and assets for all locales before submission
Use dry-run where available before destructive actions
Verify the release status and that the versionCode matches the uploaded build

Example Use Cases

Shipping a production release after updating store listing and assets
Troubleshooting a failed submission due to missing screenshots or assets
Diagnosing a release stuck in inProgress by validating status and edits
Uploading a ProGuard/R8 deobfuscation mapping when required
Performing a dry-run to catch issues before final publish

Frequently Asked Questions

Add this skill to your agents