From Claude Code to Google Play: Shipping Android Apps Built With Agents

Android is the friendlier platform for agent-driven development: Gradle runs on any operating system, the emulator works on Linux, and Claude Code can drive the whole build from a terminal. The bottleneck is rarely the code. It is the Play Console timeline, which can add weeks if you start it late. This guide is organized around that timeline.

Week 0: decisions that set the calendar

Two choices determine how long your first release takes:

• Personal or organization account. A Google Play developer account costs USD 25 once. Personal accounts created after November 13, 2023 must complete a closed test with at least 12 testers opted in for 14 consecutive days before they can apply for production access. Organization accounts require verification details such as a D-U-N-S number but, as of 2026, are not subject to that specific testing rule. Check the current Play Console Help pages, because these policies evolve.
• Who your 12 testers are. Recruiting testers who actually stay opted in for two weeks is harder than it sounds. Line them up before the build is ready.

The rule and its pitfalls are explained in detail in the Google Play 12-tester rule explained.

Week 1: make the build releasable

Give Claude Code a written definition of "releasable" and let it work through the gaps. A short release section in CLAUDE.md keeps the agent consistent across sessions:

Release rules: Build with ./gradlew bundleRelease. Never commit keystores, keystore.properties or google-services.json secrets. Bump versionCode on every upload. Keep targetSdk at the level Google Play currently requires. Run ./gradlew lint testReleaseUnitTest before declaring a task done. Do not add permissions to the manifest without listing them in the PR description.

Then have the agent check these points and report back before changing anything:

1. applicationId is final. It cannot be changed after the first upload.
2. targetSdk meets the current Play requirement, which is roughly within one year of the latest major Android release.
3. The release build type enables code shrinking (R8) and the app still works with it – reflection-heavy libraries need keep rules.
4. Every permission in the merged manifest is actually needed. Libraries add permissions you did not ask for.
5. The app handles no network, denied permissions and process death without crashing.

For the development side of this, see building an Android app with Claude Code.

Signing: keep two keys apart

New apps on Google Play use Android App Bundles (AAB) and Play App Signing. Google holds the app signing key; you hold an upload key that proves builds come from you. Generate the upload keystore yourself, store it in a password manager and in your CI secret store, and reference it through environment variables. Claude Code can write the Gradle signing config that reads those variables; it should never need the keystore password in its context. If the upload key is lost, Google can reset it, but that takes time you would rather not spend during a launch.

Weeks 1–3: closed testing that counts

Upload the first AAB to the internal testing track for a smoke test, then promote it to a closed track for the required period. Practical advice:

• Use a Google Group or email list for testers so you can add replacements without changing the track.
• Ship updates during the test. Google's production access questions ask what you learned and changed; a test with zero updates looks passive.
• Ask Claude Code to write a short changelog from merged PRs for each closed-test build. You will reuse it when answering the production access questionnaire.
• Do not reset your 14-day count by letting testers drop below 12. Track opt-ins weekly.

The Play Console forms

The Data safety form is where agent-built apps most often go wrong, because nobody knows exactly what each SDK sends. See app privacy labels and the Data safety form for a method.

Store listing assets the agent can prepare

While the closed test runs, use the waiting time for the listing. Claude Code can do much of the groundwork:

• Write UI tests that navigate to your key screens with seeded demo data, then capture screenshots automatically for phone and, if you support them, tablet sizes.
• Draft the short description (80 characters) and full description, staying within Google Play's metadata policy: no keyword stuffing, no unverifiable claims like "best" or "#1", no misleading references to other apps.
• Generate a release notes template that turns merged PR titles into user-facing language.
• Create the seeded demo account and document its credentials for the App access section.

Keep the human review step: you are responsible for every statement in the listing, and reviewers compare it with the actual app.

Production and after

Once production access is granted, roll out in stages (for example 10%, then 50%, then 100%) and watch Android vitals for crash and ANR rates. Claude Code is useful here too: paste a stack trace from the Play Console, ask for a minimal fix plus a regression test, and ship it as a new versionCode. If a release is rejected or an app is flagged, the Google Play rejection fix-it guide lists the usual causes.

If you would rather not learn the Play Console, signing and CI by trial and error, appsubmitter.io sets up the pipeline, signs and submits the builds in your own developer account and guides you through closed testing and rejections. Your code and your account stay yours.