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.
Open in Dock→Solo founders + first-time Android shippers
Publishing to Google Play is a different shape of bureaucracy than the App Store: cheaper one-time fee, but a 14-day closed-testing prerequisite for new personal accounts, a Data Safety form that has to match what your app actually sends, and a Target API level deadline that sunsets old apps every August. This playbook walks the 10 gates first-timers always miss, with the official Google links and agent prompts for the parts agents can do (drafting store listing copy, auditing third-party SDKs for the Data Safety form, generating screenshot variants).
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.
Time2-4 weeks (most of it the closed-testing prerequisite)DifficultyintermediateForSolo founders + small teams shipping their first Android app.
Top to bottom. Each step has tasks, pointers, gotchas.
01 / 10
Register the Google Play Developer account
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
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.
02 / 10
Create the app and upload your first AAB
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
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.
03 / 10
Run the 14-day closed test (personal accounts only)
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
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.
04 / 10
Write the store listing (title, descriptions, graphics)
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
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.
05 / 10
Fill out the Data Safety form accurately
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
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.
06 / 10
Hit the Target API level requirement
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
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).
07 / 10
Set up content rating, ads declaration, and target audience
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.
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.
08 / 10
Configure pricing, billing, and in-app purchases
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
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.
09 / 10
Submit for review and ship to production
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
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%.
10 / 10
Post-launch: ratings, crashes, vitals, and update cadence
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
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
Workspace-wide agent prompt.
Paste this into your agent's permanent system prompt so the agent reads, writes, and maintains the template's surfaces as you work through the steps.
Agent system prompt
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
Common questions on this template.
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.
Open this template as a workspace.
We mint a fresh copy in your org with the steps as table rows, the pointers as a separate table, and the brief as a doc. Bring your agents, start checking off boxes.