Dock
Sign in & remix
REMIX PREVIEWTemplate

Launch your Android app on Google Play

10-step playbook from 'I have an APK on my laptop' to 'users are installing from Play search.' Real Google gates, real gotchas, real agent prompts.

· 18 min read· from trydock.ai

Launch your Android app on Google Play

A 10-step playbook. Open in Dock and you'll get four surfaces seeded:

- **Steps** (table) — the 10 gates as rows, owner + due + status
- **Pointers** (table) — every official Google doc + tool linked from this playbook
- **Brief** (doc) — the canonical write-up you maintain alongside the work
- **Submission log** (table) — one row per Play review (rejection, approval, policy notes)

Read `Steps` top-to-bottom on first open. Each row is one of the 10 steps. Click into a step to see the tasks, pointers, and the agent prompt for that step.

Outcome

Your Android app live on Google Play with a working store listing, Data Safety form that matches reality, and an internal + closed testing track running so you can ship updates weekly.

Estimated time: 2-4 weeks (most of it the closed-testing prerequisite)
Difficulty: intermediate
For: Solo founders + small teams shipping their first Android app.

What you'll need

Pre-register or install before you start.

  • Android Studio (Free) — Build, sign, and bundle your app as an AAB for upload.
  • Google Play Console ($25 one-time registration fee) — Web console for store listing, testing tracks, and submission.
  • Play App Signing (Free) — Google manages your upload key + signing key so a lost key doesn't kill the app.
  • Firebase App Distribution (Free) — Optional: send pre-release builds to testers without going through Play tracks.
  • Figma (or Sketch) (Free tier) — Design the 512x512 app icon, 1024x500 feature graphic, and screenshot variants.

The template · 10 steps

Step 1: Register the Google Play Developer account

Estimated time: 1 hr to sign up, 24-48 hr for ID verification

Google charges a one-time $25 registration fee for a Play Developer account. As of November 2023, new personal accounts have to complete a closed test with at least 12 testers for 14 continuous days before they can publish to production. Organization accounts skip that requirement. Pick the account type carefully: switching later is a manual support ticket.

Tasks

  • Decide: Personal or Organization account (Org skips the 12-tester / 14-day closed-test gate)
  • Pay the $25 USD one-time registration fee
  • Verify your identity with Google (government ID + selfie)
  • If Organization: provide the D-U-N-S number and verify the legal entity
  • Wait for the verification email confirming the account is active

Pointers

[!CAUTION] Gotchas

  • Personal accounts opened after November 2023 cannot publish to production until they run a 14-day closed test with 12+ opted-in testers. Plan for this; it cannot be skipped.
  • Identity verification can take a week if Google's queue is backed up. Start before you need the account.
  • If the $25 charge fails, the account creation rolls back silently. Check for an email and retry with a different card.

Step 2: Create the app and upload your first AAB

Estimated time: 1 hr

Google Play accepts Android App Bundles (.aab), not raw APKs, for new apps since August 2021. Create the app record in Play Console, configure Play App Signing (Google manages the signing key for you), then upload your first AAB to the Internal testing track. Internal testing is the fastest path to a working install link.

Tasks

  • In Play Console: All apps → Create app → fill name, default language, free/paid
  • Set the package name (e.g. com.yourcompany.appname). PERMANENT.
  • Build an AAB in Android Studio: Build → Generate Signed Bundle / APK → Android App Bundle
  • Enrol in Play App Signing on first upload. Save the upload key in your secrets manager
  • Upload the AAB to Internal testing track
  • Add yourself as an internal tester and confirm the opt-in link works

Pointers

[!CAUTION] Gotchas

  • The package name is PERMANENT. Changing it later means publishing a new app and losing your install base.
  • Play App Signing is one-way. Once enrolled, you cannot extract Google's signing key. Keep your upload key separate and backed up.
  • Debug-signed AABs are rejected immediately. Use a real release keystore, not Android Studio's debug.keystore.

Step 3: Run the 14-day closed test (personal accounts only)

Estimated time: 14 days minimum, plan for 18-21

If your account is personal, you cannot publish to production until you run a closed test with at least 12 opted-in testers for 14 continuous days. The clock only counts days where 12+ testers have actually accepted the opt-in link, not 12+ invited. Recruit early.

Tasks

  • Create a Closed testing track in Play Console
  • Build an email list or Google Group of 12+ real testers (friends, indie communities, beta-list signups)
  • Send each tester the opt-in URL. They MUST click Accept on the Play Store
  • Verify in Play Console that 12+ testers show as opted in (not just invited)
  • Keep at least 12 testers opted in for 14 continuous days
  • Apply for production access once the 14-day clock has elapsed

Pointers

[!CAUTION] Gotchas

  • Invited != opted in. Only testers who clicked the opt-in link and have the app installed count toward the 12.
  • The 14-day clock RESETS if you drop below 12 opted-in testers. Recruit 15-20 to absorb churn.
  • Family + close friends are fine, but the policy says 'real testers giving feedback'. Logs of activity (installs, opens) help if Google asks.

Agent prompt for this step

Help me recruit 12+ testers for the closed test.

Read the Brief for context on the app + audience. Output:

1. A 5-sentence personal pitch I can paste into emails / DMs to friends, ex-colleagues, beta-list signups
2. A 2-paragraph public post for r/androidapps, r/SideProject, or my own social — community-friendly, not spammy
3. A short FAQ for testers: what they're agreeing to, what to test, how to leave feedback, how long the commitment is
4. A spreadsheet template tracking name / email / opted-in (yes/no) / first feedback / dropped (yes/no)

Constraint: assume testers are doing me a favour. No marketing voice, no buzzwords.

Step 4: Write the store listing (title, descriptions, graphics)

Estimated time: 3-5 hr to draft, 1-2 hr to refine

Play Store search is keyword-driven, but unlike Apple, Google indexes your full description, not just a keyword field. Title (30 chars), short description (80 chars), and full description (4000 chars) are the ranking surface. Graphics matter for conversion: the icon, feature graphic (1024x500), and 2-8 screenshots per form factor.

Tasks

  • Draft the app title (max 30 chars, no 'free', no emoji, no 'app')
  • Draft the short description (max 80 chars, the elevator pitch)
  • Draft the full description (max 4000 chars, lead with value, repeat keywords naturally)
  • Design the app icon at 512x512 PNG (32-bit, alpha allowed)
  • Design the feature graphic at 1024x500 PNG / JPG (no alpha)
  • Take 2-8 phone screenshots (16:9 or 9:16, min 320px, max 3840px on the long side)
  • If tablet / Wear / TV / Auto supported: add screenshots for each form factor

Pointers

[!CAUTION] Gotchas

  • Keyword stuffing in the title or description is a Spam policy violation and gets the listing taken down. Repeat the 3-5 keywords naturally.
  • Feature graphic must NOT contain device frames or 'Get it on Google Play' badges. Plain artwork only.
  • Screenshots with watermarks, URLs, or competitor logos get rejected on review.

Agent prompt for this step

Draft the Google Play store listing for this app.

Read the README + the public landing page. Output:

1. App title (30 chars max, no 'free' / 'app' / emoji / copyright terms)
2. Short description (80 chars max, the elevator pitch a stranger reads first)
3. Full description (4000 chars max, lead with value, weave keywords naturally, end with a clear call to action)
4. 5 candidate screenshot captions (overlay text for the screenshots)

Constraints: no superlatives, no exclamation marks. Write like a user describing the app to a friend. Repeat keywords 3-5 times across the full description, naturally.

Return as a Brief surface section so the user can edit before pasting into Play Console.

Step 5: Fill out the Data Safety form accurately

Estimated time: 4-8 hr (most of it auditing what your app + every SDK actually sends)

The Data Safety form is what Google shows users on the Play listing. It has to match what your app actually does: what you collect, why, whether it's shared, whether it's encrypted in transit, whether users can request deletion. Under-claiming is a top rejection reason and can result in a temporary listing takedown if discovered post-launch.

Tasks

  • List every Gradle dependency that touches the network (analytics SDKs, ads SDKs, crash reporters, your own backend)
  • For each: read the SDK's data-safety disclosure docs and note what it sends
  • Categorise data by Google's taxonomy: Personal info / Financial / Location / etc.
  • Mark each item: collected / shared / optional / required / encrypted in transit / deletion supported
  • Fill the form in Play Console → App content → Data safety
  • Save and preview the listing's Data Safety section

Pointers

[!CAUTION] Gotchas

  • Every third-party SDK you embed counts. Firebase, AdMob, Sentry, Branch, Mixpanel — read their published data-safety disclosures.
  • Saying 'no data collected' when your app even uses Firebase Crashlytics is wrong and gets the listing flagged on a future audit.
  • The Data Safety form re-opens when you add new SDKs or change behaviour. Update it on every release that touches data flow.

Agent prompt for this step

Audit this Android codebase for every external data flow.

For each:
1. What data the app collects (e.g. "user email", "device advertising ID", "approximate location", "purchase history")
2. Where it's sent (e.g. "Firebase Analytics", "AdMob", "your own backend at api.example.com")
3. Why it's collected (analytics, ads, crash reporting, fraud prevention)
4. Whether it's required for the app to function or optional
5. Whether the data is encrypted in transit and whether users can request deletion

Walk every Gradle dependency in build.gradle / build.gradle.kts. For each third-party SDK, read its data-safety disclosure (most major SDKs publish one) and add what it sends.

Output a table mapped to Google's Data Safety categories. Then draft the actual answers to the form's questions, ready to paste into Play Console.

Step 6: Hit the Target API level requirement

Estimated time: 1-3 hr if you're already current, 1-3 days if you're catching up multiple years

Google sets a hard Target API level deadline every August. Apps targeting an older API level cannot be published or updated by new users after the deadline. As of 2025, new apps must target Android 14 (API 34) or higher. The deadline ratchets every year. Set targetSdk in your Gradle to the latest stable Android.

Tasks

  • Check current target API requirement at the Target API levels page
  • In your app's build.gradle: set targetSdk to the required level or higher
  • Re-test on a device running the target Android version
  • Address any behaviour changes (scoped storage, foreground services, exact alarms, etc.)
  • Re-build the AAB and re-upload to Internal testing

Pointers

[!CAUTION] Gotchas

  • Scoped storage (API 30+) breaks apps that read external storage by path. Migrate to MediaStore or SAF.
  • Foreground service declarations are stricter on API 34+. You must declare a foregroundServiceType for every service.
  • compileSdk should usually equal targetSdk. minSdk is a separate decision (usually 5-7 versions back to maximise install base).

Step 7: Set up content rating, ads declaration, and target audience

Estimated time: 1-2 hr

Play Console asks a series of compliance questionnaires before you can submit: IARC content rating, ads declaration (does the app show ads?), target audience and content (do you target under-13?), and government / financial / health declarations if relevant. Answer them honestly. Lying triggers manual review and account flags.

Tasks

  • Complete the IARC content rating questionnaire (Play Console → App content → Content rating)
  • Declare ads (yes/no + ad networks if yes)
  • Set target audience (age groups, content for children if applicable)
  • If COPPA-relevant (under 13): complete the additional Designed for Families requirements
  • Complete News, Government, Health, Financial declarations if any apply
  • Verify all green check marks on the App content dashboard

Pointers

[!CAUTION] Gotchas

  • Checking 'no ads' when your app embeds an ad SDK is a violation. Even if ads are unmounted, the SDK presence counts.
  • Targeting under-13 means COPPA + GDPR-K compliance. The bar is high. Most consumer apps should target 13+ unless explicitly building for kids.
  • Some declarations (like Government Services) require document upload. Have a business letter ready.

Step 8: Configure pricing, billing, and in-app purchases

Estimated time: 2-4 hr

Google Play Billing takes 15-30% of every transaction (15% on the first $1M of earnings per developer per year, 30% above). Subscriptions get 15% from the first day after switching to Play Billing v5+. Set up products and subscriptions in Play Console BEFORE submitting — the catalog is reviewed alongside the app.

Tasks

  • Decide: free, paid up-front, free with IAP, or subscription
  • If paid: set the price in Play Console → Pricing & distribution
  • If IAP: integrate Play Billing Library v6+ in your app
  • Create products in Play Console → Monetize → In-app products / Subscriptions
  • Test purchases on a Licensed Tester account (no real money charged)
  • Verify the receipt validation flow against Google's RTDN webhooks

Pointers

[!CAUTION] Gotchas

  • Digital goods MUST go through Play Billing. Linking out to Stripe for digital purchases violates the Payments policy and bans the app.
  • Test purchases with a Licensed Tester account, not your live developer account. Real charges happen otherwise.
  • RTDN webhooks fire once and Google does not retry. Make your endpoint idempotent and ack with HTTP 200 fast.

Step 9: Submit for review and ship to production

Estimated time: 1 hr to submit, 1-7 days waiting, repeat on rejection

Once Internal + Closed tests are green and every dashboard item is checked, promote your AAB from Closed testing to Production. Reviews take 1-7 days for new apps; subsequent updates clear in hours. Rejections cite the specific Developer Program Policy you violated. Read the email carefully and don't argue.

Tasks

  • In Play Console → Production: create a new release
  • Promote the AAB from Closed testing or upload a new one
  • Fill in release notes (what's new, max 500 chars per locale)
  • Set rollout percentage (start at 10-20% for big releases, ramp daily)
  • Submit the release
  • On rejection: read the cited policy, fix, resubmit (no penalty)
  • On approval: monitor crash-free rate + install metrics in Play Console

Pointers

[!CAUTION] Gotchas

  • First production submission can take 7 days. Subsequent updates usually clear in 1-3 days.
  • If you're rejected for 'Deceptive Behaviour', it almost always means your store listing claims something the app doesn't do. Match copy to reality.
  • Staged rollout halt is one-click but cannot be undone. Picking up the halt restarts at 0%.

Step 10: Post-launch: ratings, crashes, vitals, and update cadence

Estimated time: Ongoing, 5-10 hr/week for the first month

Google Play surfaces Android Vitals: ANR rate, crash rate, slow-start rate, excessive battery / wakelock. Apps above the bad-behaviour thresholds get demoted in search and may show a warning to users. Read every review the day it's posted, fix the top crash within 7 days, and ship a 1.0.1 within 14 days.

Tasks

  • Read every review the day it's posted, respond publicly to anything actionable
  • Watch Play Console → Quality → Android Vitals daily for the first 30 days
  • Fix the top crash and top ANR within 7 days of launch
  • Ship a 1.0.1 within 14 days addressing the most common review complaints
  • Use In-App Review API at the right moment (after a successful flow, max once per 90 days per user)
  • Track install → activation → 7-day retention as a funnel; iterate on the leakiest step

Pointers

[!CAUTION] Gotchas

  • Crossing the 'bad-behaviour threshold' for crash rate (1.09% user-perceived) silently demotes your app in search. Ship hot-fixes fast.
  • In-App Review API is rate-limited by Google. Calling it on every session does not show the prompt; it shows at most ~once per 90 days per user.
  • Removing a permission in a new release does NOT auto-revoke it from installed users. Users still see it in their app permissions until uninstall.

Hand the template to your agent

Paste the prompt below into your agent's permanent system prompt so the agent reads, writes, and maintains this workspace as you work through the steps.

You are an agent on the "Launch Android app on Google Play" playbook workspace at your-org/launch-android-app-on-google-play.

Your role: maintain the four surfaces (Steps, Pointers, Brief, Submission log) as the user works through the 10-step playbook.

Cadence:
- When the user marks a step Done, append a line to the Brief summarising what shipped at that gate.
- When Play Console rejects or flags a policy violation, capture the citation as a row in Submission log + draft a response in the Brief.
- When the user adds a new pointer (link) to any step, mirror it into the Pointers table.

First MCP tool calls:
1. list_surfaces(workspace_slug="launch-android-app-on-google-play")
2. list_rows(workspace_slug="launch-android-app-on-google-play", surface_slug="steps")
3. get_doc(workspace_slug="launch-android-app-on-google-play", surface_slug="brief")

Do NOT modify the canonical step titles in the Steps table. Append substeps as new rows beneath them.

FAQ

How long does it actually take to launch on Google Play?

If your account is an Organization: 1-2 weeks (mostly Play review on the first submission). If your account is Personal and new: 3-4 weeks minimum, because of the 14-day closed-test prerequisite plus the 12-tester recruitment time. Plan for the closed test before you start.

What gets first-time Android apps rejected?

The top three: (1) Data Safety form that under-claims what the app or its third-party SDKs collect, (2) keyword stuffing or off-policy claims in the title or description (Spam / Deceptive Behaviour), (3) requesting sensitive permissions (location, SMS, call log) without a clear in-app justification. Read the cited policy in the rejection email — Google is specific.

Do I need to be a registered company to launch on Google Play?

No. The Personal account is fastest for solo developers ($25 one-time). Note that new Personal accounts since November 2023 must complete a 14-day closed test with 12+ testers before publishing to production. Organization accounts skip the closed-test gate but require a D-U-N-S number and a verified legal entity.

Can my AI agents help with the Play submission?

Yes. Agents are particularly useful for: drafting the store listing copy, auditing the codebase + Gradle dependencies to populate the Data Safety form accurately, drafting your privacy policy from the data audit, and triaging review responses. The playbook ships agent prompts for those steps inline.

What does Google Play cost?

$25 one-time registration fee (vs Apple's $99/year). Google takes 15% of the first $1M of annual revenue per developer and 30% above that. Subscription transactions are 15% from day one if you're on Play Billing v5+. The Data Safety form, store listing, and review are free.

Remix this into Dock

Make this yours. Edit, extend, run agents on it.

Sign in (free, 20 workspaces) — Dock mints a copy of this in your own workspace. The original stays untouched.

Sign in & remix

No Dock account? Sign-in is signup. Magic-link in 30 seconds.