DEV Community: Yasser's studio

I built the first Android publishing CLI with Managed Google Play support

Yasser's studio — Sat, 11 Apr 2026 16:30:08 +0000

If you ship a private Android app to enterprise customers, you've probably noticed something:

No publishing CLI supports it.

Fastlane supply, the most popular Android publishing tool, wraps the standard Google Play Publisher API. Gradle Play Publisher does the same. They both handle public Play Store releases well (upload AAB, promote tracks, manage rollouts), but neither touches the Play Custom App Publishing API (the API for publishing private apps to Managed Google Play).

If you need to publish a private app, you have two options today:

Click through Google Play Console for every release (takes 1-2 hours)
Write your own Google API client against the Custom App API from scratch

I just shipped v0.9.56 of GPC (a Play Console CLI I've been building for the past few months) with native support for this API. GPC is the first Android publishing CLI to wrap the Play Custom App Publishing API end to end.

Now option 3 exists:

gpc enterprise publish ./app.aab \
  --account 1234567890 \
  --title "My Internal App" \
  --org-id customer-org

Five minutes instead of two hours.

What's a "private app" on Managed Google Play?

Managed Google Play is Google's app store for enterprise-managed Android devices. Apps fall into two buckets:

Public apps are regular Play Store apps that enterprises can approve and distribute to their employees. Nothing special on the publishing side.
Private apps are custom apps distributed exclusively to specific enterprise customers. Invisible to the public Play Store. Created via a separate Google API called the Play Custom App Publishing API.

This matters for you if you build:

An internal app for your own company's managed Android fleet
A vertical SaaS product with a per-customer Android client
A line-of-business app that only one enterprise customer installs
A private B2B tool distributed through Managed Google Play

If your app is public Play Store fare, skip this article. GPC's regular commands work for you and always have.

Why nobody wrapped this API

The Play Custom App Publishing API is tiny. Google's discovery document exposes exactly one method:

POST /playcustomapp/v1/accounts/{account}/customApps

That single method creates a new private app and uploads the bundle. There's no list method. No update method. No delete method. Apps created through this API are permanently private and can never be converted to public apps later.

Because the API is small and the audience is narrow, nobody has productized a wrapper for it. The tools that handle 99% of Android publishing (Fastlane, gradle-play-publisher) target the 99% use case: public Play Store releases.

But if you're in the 1% shipping to enterprise, every release is a painful manual slog in Play Console. The Custom App flow requires you to:

Open Play Console
Click through the Create app wizard
Manually enter title and language
Upload the AAB
Click through organization assignment
Confirm a permanent-privacy warning
Wait for Google's backend to process the upload
Copy the assigned package name somewhere so you can reference it later

One release takes 1-2 hours. If you're shipping weekly, that's 4-8 hours a month of manual clicking.

The multipart resumable upload gotcha

When I first tried to wrap this API, I hit an interesting challenge. The Play Custom App Publishing API uses multipart resumable upload: the JSON metadata (title, language code, target organizations) and the bundle binary travel together in a single resumable session.

The session-initiation POST carries the JSON metadata in its body. Subsequent PUT requests stream the binary in chunks to the session URI Google returns.

This is different from the standard Publisher API, which uses simple uploadType=media uploads where the body is just raw binary. GPC already had a resumable upload helper, but it was designed for the Publisher API pattern (empty initial POST body). I had to extend it:

// Before: initial session POST sent an empty body
// After: optional initialMetadata parameter drives a JSON body on init
export interface ResumableUploadOptions {
  chunkSize?: number;
  onProgress?: (event: UploadProgressEvent) => void;
  // ... existing options

  /**
   * Optional JSON metadata to include in the initial session-initiation POST.
   * When present, the initial request uses Content-Type: application/json; charset=UTF-8
   * and the serialized body. When omitted, the initial request sends an empty body
   * (default Publisher API behavior).
   */
  initialMetadata?: object;
}

This generalization turned out to be valuable beyond just the Custom App API: any Google API that follows the same "metadata in init POST, binary in chunks" pattern can now use the same helper.

What the command actually looks like

The CLI surface is intentionally simple:

# One-shot publish (most common path)
gpc enterprise publish ./app.aab \
  --account 1234567890 \
  --title "My Internal Tool" \
  --org-id customer-org \
  --yes                      # skip confirmation in CI

# Explicit-arg form
gpc enterprise create \
  --account 1234567890 \
  --bundle ./app.aab \
  --title "My Internal Tool" \
  --org-id customer-org

# Multiple target organizations
gpc enterprise publish ./app.aab \
  --account 1234567890 \
  --title "Multi-Customer Client" \
  --org-id org-acme  --org-name "Acme Corp" \
  --org-id org-beta  --org-name "Beta Inc"

The --account argument is the long integer you read from the Play Console URL:

https://play.google.com/console/developers/1234567890/...
                                             ^^^^^^^^^^

It's not a Google Workspace organization ID. Not a Cloud Identity ID. Just the developer account ID. (This confused me for a while building the feature, and it confuses users hitting the docs for the first time too.)

One-way door: permanently private

Apps created through this API cannot be made public later. GPC prints a confirmation prompt before every create/publish call to make sure you meant it:

⚠  This will publish a PRIVATE app to Managed Google Play.

   Private apps created via this API are permanently private and cannot be converted
   to public apps later.

   Developer account: 1234567890
   Title:             My Internal Tool
   Language:          en_US
   Bundle:            ./app.aab
   Organizations:     customer-org

Continue with private app creation? [y/N]:

Pass --yes to skip the prompt in CI or non-interactive environments. The CLI will refuse to proceed on a non-TTY without --yes, which prevents accidental creates from unattended scripts.

What happens after the initial publish

Here's the part that surprised me while building this feature: after a private app is created, it becomes a regular app in your developer account.

It has a packageName that Google assigns (something like com.google.customapp.A1B2C3D4E5). You can't influence the package name. But once the app exists, you can use every other GPC command against it:

# Save the package name from the create step
APP_ID=com.google.customapp.A1B2C3D4E5

# Upload a new version like any other app
gpc --app $APP_ID releases upload ./app-v2.aab --track production

# Promote between tracks
gpc --app $APP_ID releases promote --from beta --to production --rollout 10

# Sync listings
gpc --app $APP_ID listings push --dir metadata/

# Query crash rates
gpc --app $APP_ID vitals crashes --threshold 2.0

None of this requires the Custom App API. It all goes through the regular Play Publisher API, same as any other app in your account. The private app is private in distribution (only visible to the organizations you assigned at create time), but administratively it's just another draft app.

The only thing you can't do programmatically is add or remove target enterprise organizations after creation. Google's API doesn't expose that. You have to open Play Console UI and do it there.

CI/CD recipe

For teams that want to automate private app publishing from a pipeline, here's a working GitHub Actions example:

name: Publish private app

on:
  workflow_dispatch:
    inputs:
      flow:
        description: "Initial publish or version update?"
        type: choice
        options: [update, initial]

jobs:
  publish:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 24
      - run: npm install -g @gpc-cli/cli

      - name: Write service account key
        run: echo '${{ secrets.GPC_SA_KEY }}' > /tmp/sa.json
        env:
          GPC_SERVICE_ACCOUNT_KEY: /tmp/sa.json

      - name: Initial publish
        if: inputs.flow == 'initial'
        run: |
          gpc enterprise --account ${{ secrets.DEVELOPER_ACCOUNT_ID }} \
            publish ./app.aab \
            --title "Internal Tools" \
            --org-id ${{ secrets.CUSTOMER_ORG_ID }} \
            --yes

      - name: Update existing
        if: inputs.flow == 'update'
        run: |
          gpc --app com.google.customapp.A1B2C3D4E5 \
              releases upload ./app.aab --track production

The workflow takes a choice input that routes to either the one-time gpc enterprise publish path or the ongoing gpc releases upload path.

Required setup (one-time)

Before you can run gpc enterprise publish for the first time, you need four things:

A Google Play developer account. The one whose ID you'll pass as --account.
The Play Custom App Publishing API enabled in a Google Cloud project. Enable it here.
A service account with the "create and publish private apps" permission in Play Console. This is a Play Console permission (Account permissions, not per-app), separate from Google Cloud IAM.
Organization IDs for the enterprise customers you want to target. Your customers provide these.

GPC's gpc doctor command includes a probe for this API. Run it to verify setup before your first publish attempt:

gpc doctor

Look for:

✓ Play Custom App Publishing API is reachable

If the probe fails, the error message points at the specific setup step that's incomplete.

Install

# npm (Node.js 20+)
npm install -g @gpc-cli/cli

# Homebrew (macOS/Linux)
brew install yasserstudio/tap/gpc

# Standalone binary (no Node.js required)
curl -fsSL https://raw.githubusercontent.com/yasserstudio/gpc/main/scripts/install.sh | sh

Free to use

GPC's source is on GitHub. It's free to use for commercial and personal projects. If you hit a bug or have a feature request, open an issue.

Full release notes: https://github.com/yasserstudio/gpc/releases/tag/v0.9.56
Enterprise publishing guide: https://yasserstudio.github.io/gpc/guide/enterprise-publishing
All commands: https://yasserstudio.github.io/gpc/commands/

Next on the roadmap: a v0.9.57 batch of API client fixes (uncovered during an audit that led to the v0.9.56 enterprise rewrite), then v1.0.0 stable.

If you're shipping to Managed Google Play and GPC saves you time, I'd love to hear about it.

I shipped a release to 10% of users. Crash rate started climbing. I found out 20 minutes later when I happened to open the Play Console.

Yasser's studio — Mon, 06 Apr 2026 12:21:12 +0000

I shipped a release to 10% of users. Crash rate started climbing. I found out 20 minutes later when I happened to open the Play Console.

That's too late. At 10%, you're already affecting real users. By the time you halt the rollout, investigate, and push a fix, you've lost reviews and trust you won't get back.

The frustrating part: the data was there the whole time. Google's API had my crash rate. I just wasn't checking it before the rollout progressed.

The gap in most Android CI pipelines

A typical Android release pipeline does three things:

Build the AAB
Run unit tests
Upload to the Play Store

That's it. The pipeline considers itself done after the upload.

But "shipped" and "healthy" are not the same thing. Nothing in that pipeline asks: is the app actually in good shape right now? Is it safe to keep rolling out?

The answer to both questions is sitting in the Play Developer Reporting API. It just needs to be checked.

gpc vitals crashes --threshold

gpc vitals crashes --threshold 2.0

That's the gate. If the crash rate exceeds 2.0%, GPC exits with code 6. Your CI sees a non-zero exit code. The pipeline stops.

Same for ANR:

gpc vitals anr --threshold 0.47

0.47% is Google's own "bad behavior" threshold for ANR. Exceed it and Play Console flags your app. Gate on it in CI and you find out before Google does.

What exit code 6 means

GPC uses semantic exit codes. Exit code 6 specifically means "quality threshold breached" -- not a crash, not an auth failure, not a network error. Your CI can react differently to each:

gpc vitals crashes --threshold 2.0 --json
EXIT_CODE=$?

case $EXIT_CODE in
0) echo "Vitals healthy" ;;
6) echo "Threshold breached -- halting rollout" ;;
3) echo "Auth error -- check your service account" ;;
4) echo "API error -- check permissions" ;;
esac

Google's actual thresholds

For reference, here are the levels Google Play uses internally:

┌────────────┬──────────────────────────┬─────────────────────────────────────────┐
│ Metric │ Google warning threshold │ What happens │
├────────────┼──────────────────────────┼─────────────────────────────────────────┤
│ Crash rate │ 1.09% │ Play Console warning, visibility impact │
├────────────┼──────────────────────────┼─────────────────────────────────────────┤
│ ANR rate │ 0.47% │ Play Console warning, visibility impact │
└────────────┴──────────────────────────┴─────────────────────────────────────────┘

A practical approach: set your CI gate at 1.5x the Google threshold. That gives you a window to catch regressions before Google flags your app.

# Conservative: catch it before Google does
gpc vitals crashes --threshold 1.5

# Standard: roughly 2x Google's threshold
gpc vitals crashes --threshold 2.0

# Emergency: last line of defense
gpc vitals crashes --threshold 3.0

In CI: one step before the rollout increase

The pattern that works best is running a vitals gate before each rollout percentage increase, not just before the initial upload.

# GitHub Actions

name: Check crash rate before rollout increase
run: gpc vitals crashes --threshold 2.0 --json
name: Increase rollout to 25%
run: gpc releases rollout increase --track production --to 25

If the vitals check exits 6, the increase step never runs. No manual intervention needed.

For a full gate covering both crash and ANR:

name: Vitals gate
run: |
gpc vitals crashes --threshold 2.0 --json
gpc vitals anr --threshold 0.47 --json
name: Increase rollout to 50%
run: gpc releases rollout increase --track production --to 50

Handling a breach

When a threshold is breached, you probably want to do more than just fail the job. You want to halt the active rollout too:

name: Vitals gate
id: vitals
run: gpc vitals crashes --threshold 2.0 --json
continue-on-error: true
name: Halt rollout on breach
if: steps.vitals.outcome == 'failure'
run: |
echo ":⚠️:Crash threshold breached -- halting rollout"
gpc releases rollout halt --track production --json

Now the pipeline detects the breach, stops the rollout automatically, and surfaces a warning in your CI logs.

The full staged rollout pattern

This is how I structure releases now. Vitals gate at every step:

Bad releases get caught early, at low rollout percentages, before they affect most of your users.

The overview command for a quick health check

If you want a full picture before you start a rollout:

gpc vitals overview

{
"crashRate": { "value": 1.2, "threshold": "bad" },
"anrRate": { "value": 0.3, "threshold": "good" },
"slowStartRate": { "value": 5.1, "threshold": "acceptable" },
"slowRenderingRate": { "value": 2.8, "threshold": "good" },
"excessiveWakeupRate": { "value": 0.1, "threshold": "good" },
"stuckWakelockRate": { "value": 0.05, "threshold": "good" }
}

Six metrics in one call. Add it as a pre-release sanity check before any upload.

Quick context on GPC

If you're new to this series: GPC is a CLI that covers the entire Google Play Developer API. 215 endpoints. 7 TypeScript packages. 1,874 tests.

Part 1: I built a CLI that covers the entire Google Play Developer API
Part 2: I replaced 4 Play Console tabs with one terminal command
Part 3: I stopped submitting to Google Play without running this first

Try it

# npm
npm install -g @gpc-cli/cli

# Homebrew
brew install yasserstudio/tap/gpc

# Standalone binary (no Node.js required)
curl -fsSL https://raw.githubusercontent.com/yasserstudio/gpc/main/scripts/install.sh | sh

Then:

gpc auth login
gpc vitals crashes --threshold 2.0

Docs | GitHub | Vitals gates docs

Free to use. Code is on GitHub.

Does your release pipeline gate on app health before increasing rollout? Curious what thresholds people use in practice.

I stopped submitting to Google Play without running this first

Yasser's studio — Thu, 02 Apr 2026 09:53:18 +0000

Last year I uploaded an AAB to the Play Console, waited four days for review, and got rejected.

The reason: targetSdkVersion was one level below the new minimum. Google had bumped the requirement that month. I hadn't noticed.

I fixed it, re-uploaded, waited another three days. That's a week lost for a one-line fix in my build config.

The frustrating part: I could have caught that before uploading. The information was right there in the manifest. I just didn't check.

The pattern

Most Play Store rejections follow the same pattern:

Upload your AAB
Wait 1-7 days for review
Get a short rejection email
Fix something you could have checked locally
Re-upload, wait again

And the rejection reasons are almost always predictable. targetSdk below the minimum. A restricted permission you didn't declare properly. A third-party billing SDK that violates Play's billing
policy. A hardcoded API key in the bundle.

None of these require Google's review to catch. They're all checkable from the file itself.

gpc preflight

$ gpc preflight app.aab

9 scanners run against your AAB file. Entirely offline. No API calls, no credentials, no network.

Here's what each scanner checks:

Manifest validation

The big one. Parses your AndroidManifest.xml from the bundle and checks:

targetSdkVersion below Google's current minimum (critical)
debuggable flag left on in a release build
testOnly flag set
Missing android:exported on components (required since API 31)
Missing foregroundServiceType (required since API 34)
Cleartext HTTP traffic enabled

✗ CRITICAL targetSdkVersion 33 is below minimum 35
Google Play requires targetSdkVersion >= 35 for new app updates.
→ Update targetSdkVersion in your build.gradle to 35 or higher.

This single check would have saved me that week.

Permissions audit

Flags 16+ restricted Google Play permissions:

SMS and call log access (heavily restricted since 2019)
QUERY_ALL_PACKAGES (requires declaration)
Background location
Accessibility service
VPN service
INSTALL_PACKAGES
REQUEST_DELETE_PACKAGES

Each finding includes a note about what data safety declarations you'll need.

Native library architecture

Checks your native libraries for 64-bit compliance:

arm64-v8a is required
x86_64 recommended
Warns if native libs total exceeds 150MB uncompressed

Metadata validation

If you pass --metadata

, it checks your Fastlane-format store listings:

Title under 30 characters
Short description under 80 characters
Full description under 4,000 characters
At least 2 phone screenshots
Privacy policy URL present

Secrets detection

Scans your source directory (with --source

) for hardcoded credentials:

AWS access keys (AKIA...)
Google API keys (AIza...)
Stripe live keys (sk_live_...)
RSA/EC/DSA private keys
Firebase config keys
Generic bearer tokens

You'd be surprised how often these end up in a bundle.

Billing compliance

Detects non-Play billing SDKs that violate Google's billing policy:

Stripe SDK
Braintree
PayPal
Razorpay
Adyen
Square

These are flagged as warnings. Some apps have exemptions, but most don't.

Privacy and tracking

Identifies tracking SDKs and cross-references with your permissions:

Facebook SDK, Adjust, AppsFlyer, Amplitude, Mixpanel, Branch, CleverTap
Advertising ID usage
Data collection indicators vs declared permissions

Policy heuristics

Pattern-matches for common policy traps:

COPPA/Families indicators (child-targeted features + data collection)
Financial app indicators (SMS access + autofill)
Health app indicators (body sensor permissions)
User-generated content indicators
System alert window (overlay) permission

Size analysis

Breaks down your bundle size by category:

ℹ INFO Total size: 64.8 MB compressed, 212.6 MB uncompressed
909 files. Breakdown: native-libs: 31.1 MB, dex: 7.2 MB,
assets: 1.1 MB, resources: 0.8 MB, signing: 0.1 MB

Warns if total download size exceeds the configurable limit (default: 150 MB). Flags individual native libs over 50 MB and assets over 30 MB.

Severity levels

Every finding has a severity:

┌──────────┬───────────────┬───────────────────────────────────────┐
│ Level │ Icon │ Meaning │
├──────────┼───────────────┼───────────────────────────────────────┤
│ critical │ ✗ (red, bold) │ Will almost certainly cause rejection │
├──────────┼───────────────┼───────────────────────────────────────┤
│ error │ ✗ (red) │ Likely to cause rejection │
├──────────┼───────────────┼───────────────────────────────────────┤
│ warning │ ⚠ (yellow) │ Worth reviewing, may cause issues │
├──────────┼───────────────┼───────────────────────────────────────┤
│ info │ ℹ (gray) │ Informational, no action needed │
└──────────┴───────────────┴───────────────────────────────────────┘

By default, the command exits code 6 if any finding is error or higher. Override with --fail-on:

gpc preflight app.aab --fail-on critical # only fail on critical
gpc preflight app.aab --fail-on warning # strict mode

In CI

Add one step before your upload:

name: Pre-submission check
run: gpc preflight app.aab
name: Upload to Play Store
run: gpc releases upload app.aab --track internal

If preflight fails (exit code 6), the upload never happens. You find out in your CI logs instead of in a rejection email three days later.

Configuration

For teams, drop a .preflightrc.json in your project root:

{
"failOn": "error",
"targetSdkMinimum": 35,
"maxDownloadSizeMb": 150,
"allowedPermissions": ["android.permission.CAMERA"],
"disabledRules": ["billing-third-party"],
"severityOverrides": {
"size-total-warning": "info"
}
}

Whitelist permissions your app legitimately needs. Disable rules that don't apply. Override severities for your specific situation.

What it doesn't catch

To be clear about the limits:

It can't check your app's runtime behavior
It can't verify your data safety form matches reality
It can't predict policy changes Google hasn't announced
It can't check things that require running the app (ANR patterns, performance)

It checks what's checkable from the file and your source. The static stuff. The things that are embarrassing to get rejected for because they were right there the whole time.

Run specific scanners

Don't need all 9? Run individual scanners:

gpc preflight manifest app.aab # manifest only
gpc preflight permissions app.aab # permissions only
gpc preflight metadata ./fastlane # metadata only
gpc preflight codescan ./src # secrets + billing + privacy

Quick context on GPC

If you're new here: GPC is a CLI that covers the entire Google Play Developer API. 208 endpoints. 7 TypeScript packages. 1,863 tests.

Previous articles in this series:

Part 1: I built a CLI that covers the entire Google Play Developer API
Part 2: I replaced 4 Play Console tabs with one terminal command

Try it

# npm
npm install -g @gpc-cli/cli

# Homebrew
brew install yasserstudio/tap/gpc

# Standalone binary (no Node.js required)
curl -fsSL https://raw.githubusercontent.com/yasserstudio/gpc/main/scripts/install.sh | sh

Then:

gpc preflight your-app.aab
gpc preflight your-app.aab --source ./src --metadata ./fastlane

Docs | GitHub | Preflight docs

Free to use. Code is on GitHub.

What's your pre-submission process look like? Manual checklist, automated, or just upload and hope for the best?

I replaced 4 Play Console tabs with one terminal command

Yasser's studio — Wed, 01 Apr 2026 09:09:21 +0000

I used to start every morning the same way.

Open the Play Console. Check the releases tab. Switch to the vitals tab. Look at crash rates. Look at ANR rates. Open the reviews tab. Scan for 1-star reviews. Cross-reference everything in my head.

Four tabs. Ten minutes. Every single day.

And I still wasn't sure if I had the full picture.

One command instead of four tabs

$ gpc status

App: com.example.app  (fetched just now)

RELEASES
  production   v142   completed    -
  beta         v143   inProgress  10%
  internal     v144   draft        -

VITALS  (last 7 days)
  crashes     0.80% ↓  ✓    anr         0.20% ↓  ✓
  slow starts 2.10%    ✓    slow render 4.30%    ⚠

REVIEWS  (last 30 days)
  ★ 4.6   142 new   89% positive   ↑ from 4.4

Ten API calls fire in parallel. Full picture in under 3 seconds.

Releases by track with rollout percentages. Four vitals metrics with trend arrows showing whether things are getting better or worse. Review sentiment with rating trends.

That's gpc status. It replaced the tab-switching ritual I used to do after every deploy.

Most release tools stop at uploads. This one doesn't.

Fastlane supply pushes your AAB and syncs metadata. That's valuable. But it's only half the story.

After you ship, you need visibility. Is the crash rate spiking on the new version? Did ANR rates jump? Are users leaving angry reviews about the change you just pushed?

Nothing else answers those questions from the terminal. gpc status closes the loop between "I shipped a release" and "here's what happened after."

Ship and monitor from the same tool.

Three workflows where this changes things

1. The morning check

gpc status --all-apps

Runs the full status check for every app in your profiles. Up to 5 apps, one command. If any app has a threshold breach, the command exits code 6.

This replaced my entire morning Play Console routine. I open the terminal, run one command, and know exactly where everything stands.

2. Watching a rollout in real time

gpc status --watch 60 --notify

Polls every 60 seconds. Clears the screen before each update. Sends a desktop notification when a threshold is breached or clears.

Leave it running on a secondary monitor during a staged rollout. Your crash rate ticks up past your threshold? You know immediately. Not 30 minutes later when you remember to check the Console.

After the rollout, check what changed:

gpc status --since-last

Changes since 1h ago:
  Version:    141 → 142
  Crash rate: 1.80% → 0.80% (-1.00%) ✓
  ANR rate:   0.30% → 0.20% (-0.10%) ✓
  Reviews:    4.4★ → 4.6★ (+0.2) ✓

3. Automated health gates in CI

This is where gpc status goes from "nice to have" to "catches problems before users do."

Gate a rollout on vitals:

gpc status --sections vitals
gpc releases rollout increase --track production --to 50

If vitals are breached, gpc status exits code 6 and the rollout never happens. No dashboards. No manual checks. Just a threshold and an exit code.

Post-deploy snapshot:

gpc status --format summary --refresh

com.example.app · v142 production · crashes 0.80% ↓ ✓ · ANR 0.20% ↓ ✓ · avg 4.6★ · 142 reviews

One line. Add it as the last step in your deploy pipeline. Something to look at when reviewing CI logs the next morning.

Parse specific metrics:

# Get crash rate
gpc status --output json | jq '.vitals.crashes.value'

# Check if all vitals are passing
gpc status --output json | jq -e '[.vitals | to_entries[].value.status] | all(. == "ok")'

The JSON output gives you values, thresholds, trend direction, and status for each metric. Build whatever monitoring logic you need on top.

The details that matter

Thresholds are configurable. The defaults (2% crash, 1% ANR, 5% slow starts, 10% slow render) work for most apps. Override them globally in .gpcrc.json, per-project with gpc config set, or per-run with --threshold crashes=1.5,anr=0.5.

Caching is built in. Results are cached for 1 hour by default. Subsequent runs in the same window cost zero API calls. Force a fresh fetch with --refresh. Read from cache only with --cached.

Section filtering saves quota. --sections vitals skips the releases and reviews API calls entirely. Fetch only what you need.

Exit codes are semantic. 0 means all clear. 2 means usage error. 4 means API error. 6 means a vitals threshold was breached. Your CI knows why something failed without parsing log output.

Quick context on GPC

If you didn't read the first article in this series: GPC is a CLI that maps the entire Google Play Developer API. 204 endpoints. 7 TypeScript packages. 1,845 tests with 90%+ coverage on every core package.

gpc status is one of 40+ commands. But it's the one I run the most.

Try it

# npm
npm install -g @gpc-cli/cli

# Homebrew
brew install yasserstudio/tap/gpc

# Standalone binary (no Node.js required)
curl -fsSL https://raw.githubusercontent.com/yasserstudio/gpc/main/scripts/install.sh | sh

Then:

gpc auth login
gpc status

Docs | GitHub | Status command docs

Free to use. Code is on GitHub.

What does your post-release monitoring look like? Are you checking dashboards manually, or do you have something automated? Genuinely curious.

I built a CLI that covers the entire Google Play Developer API

Yasser's studio — Tue, 31 Mar 2026 08:53:17 +0000

I was uploading an AAB to the Play Console last year and thought — why am I still clicking through this in 2026?

Every Android release is the same ritual. Open the Console, upload the bundle, fill in release notes, pick a track, set the rollout percentage, click through confirmation screens. Fifteen minutes of clicking for
something that should be one command.

So I looked at what exists.

Fastlane supply requires Ruby, Bundler, and about 150 gems. It covers roughly 20 of the 204 Google Play API endpoints. Uploads and metadata — that's about it. No reviews, no vitals, no subscriptions.

gradle-play-publisher is tied to Gradle. You can't use it in a standalone script or outside a build.

Custom bash scripts work until the person who wrote them leaves your team.

Nothing covers the full API. So I built one.

What is GPC?

GPC is a command-line interface that maps the entire Google Play Developer API v3 — 204 endpoints — to simple, consistent commands.


bash
  # Upload and release
  gpc releases upload app.aab --track beta

  # Check vitals
  gpc vitals crashes --version 142

  # Read reviews
  gpc reviews list --stars 1-2 --since 7d

  # Manage subscriptions
  gpc subscriptions list

  It runs on Node.js, installs via npm, Homebrew, or as a standalone binary (no Node.js required). Cold start is under 500ms. Works on macOS, Linux, and Windows.

  It's not just a release tool

  The part that surprised me during development was how much of the Play Console is actually accessible through the API that nobody builds tools for.

  You can sync store listings across 70+ languages. Pull crash data and ANR rates into your monitoring pipeline. Gate a rollout on vitals — if your crash rate spikes, GPC refuses to increase the rollout and tells
  you why. Manage subscriptions, verify purchases, convert pricing across regions.

  But two commands ended up being my most used:

  Preflight — catch policy violations before Google does

  gpc preflight app.aab


Runs 9 parallel scanners on your AAB — entirely offline, no API calls. Checks targetSdk compliance, missing exported flags, restricted permissions, hardcoded API keys, non-Play billing SDKs, privacy/tracking issues, COPPA flags, download size, and store listing metadata.

You get a findings report with severity levels. In CI, exit code 6 means something needs fixing before you upload.

I built this because I was tired of uploading a bundle and finding out two hours later that it was rejected. Now it's the first thing that runs in my pipeline.

Status — your app's health in one command

gpc status

Fires 10 parallel API calls and gives you a snapshot: active releases by track, crash rate, ANR rate, slow start rate, slow render rate, and recent reviews — with trend arrows and threshold indicators.

Add --watch 30 and it polls every 30 seconds. Add --notify and you get a desktop notification when a threshold is breached. --since-last shows what changed since your last check.

This replaced the "open three Console tabs and cross-reference" workflow I used to do after every release.

Built for CI/CD

  I designed GPC for pipelines from day one.

  - name: Upload to Play Store
    env:
      GPC_SERVICE_ACCOUNT: ${{ secrets.SA_KEY }}
    run: |
      npm install -g @gpc-cli/cli
      gpc preflight app.aab
      gpc releases upload app.aab --track internal
      gpc status --format summary

  A few things that make this work well:

  - TTY-aware output — tables in your terminal, JSON when piped. No flags needed.
  - Semantic exit codes — 3 means auth failed, 4 means API error, 6 means your crash rate threshold was breached. Your CI can react differently to each.
  - --dry-run on every write operation — test your pipeline without shipping to production.
  - Vitals gating — block a rollout increase if crash/ANR rates exceed your threshold. One flag.

  The architecture

  GPC is a TypeScript monorepo with 7 publishable packages:

  ┌─────────────────────┬──────────────────────────────────────────┐
  │       Package       │               What it does               │
  ├─────────────────────┼──────────────────────────────────────────┤
  │ @gpc-cli/cli        │ The CLI you run                          │
  ├─────────────────────┼──────────────────────────────────────────┤
  │ @gpc-cli/core       │ Business logic and command orchestration │
  ├─────────────────────┼──────────────────────────────────────────┤
  │ @gpc-cli/api        │ Typed Google Play API client             │
  ├─────────────────────┼──────────────────────────────────────────┤
  │ @gpc-cli/auth       │ Service account, OAuth, ADC              │
  ├─────────────────────┼──────────────────────────────────────────┤
  │ @gpc-cli/config     │ Config loading, profiles, env vars       │
  ├─────────────────────┼──────────────────────────────────────────┤
  │ @gpc-cli/plugin-sdk │ Plugin interface for extensions          │
  ├─────────────────────┼──────────────────────────────────────────┤
  │ @gpc-cli/plugin-ci  │ CI/CD helpers                            │
  └─────────────────────┴──────────────────────────────────────────┘


The key decision was TypeScript over Go. The existing play-console-cli is written in Go — fast binary, zero deps. But Android developers already have Node.js (React Native, build tools), npm is already in every
  CI pipeline, and @gpc-cli/api works as a standalone SDK in any Node.js project.

  Go gives you a binary. TypeScript gives you an ecosystem.

  Where it stands

  - 204 Google Play API endpoints — all covered
  - 1,845 tests, 90%+ line coverage on every core package
  - Available on npm, Homebrew, and as a standalone binary
  - Fastlane metadata format compatible (drop-in for store listings)
  - Plugin system with lifecycle hooks
  - Interactive mode for when you don't remember the flags

  It's pre-1.0, but it's the most tested project I've shipped, and I use it for my own apps.

  Get started

# npm
  npm install -g @gpc-cli/cli

# Homebrew
  brew install yasserstudio/tap/gpc

# Standalone binary
  curl -fsSL https://raw.githubusercontent.com/yasserstudio/gpc/main/scripts/install.sh | sh

  - Docs: yasserstudio.github.io/gpc
  - GitHub: github.com/yasserstudio/gpc

It's free to use. Code is on GitHub.

If you ship Android apps — what's the one thing about the Play Console you wish you could automate? I'm genuinely curious and happy to prioritize it.