Same role as the iOS stack. Spend the planning time before you open the IDE. Android also has Play Store policies that bite late-discovered scope (background location, accessibility services, foreground service types).
Android app with AI
Same shape as the iOS stack, swap the platform tools. Cursor handles Kotlin and Jetpack Compose well. Android Studio's Gemini integration covers the simple completions; AI agents in Cursor cover the multi-file work. Distribute via the Play Console after a one-time $25 fee.
Strong Kotlin completions, Composer for cross-screen edits, and good interop with Gradle config files. Cursor handles Compose's declarative style well.
Where the app actually builds and signs. Studio's Gemini is fine for inline completions if you want a second opinion. Profilers (CPU/Memory/Energy) are essential for the Play Store's Android Vitals section.
- claudeFree tier
- cursor$20
- android-studioFree
- + play-account$2 (one-time $25, annualized)
- claude$20
- cursor$20
- android-studioFree
- + play-account$2
- claude$20
- cursor$200 (5x $40 Business)
- android-studioFree
- + play-account$0 (org-wide)
- 1Plan in ClaudeClaude
Same scoping pass as the iOS stack — but the Play Store review concerns are different.
Prompt · Android app scoping promptPlan a small Android app for the idea below. Don't write Kotlin yet. Idea: """ {{1-line product description}} """ Constraints: - Jetpack Compose only. No XML layouts unless legacy interop forces it. - Single-activity architecture with Navigation Compose. - Local-first storage (Room) unless I ask for sync. - No background services unless I justify the foreground service type. - No accessibility services unless explicitly asked (Play Store policy gate). Output, in this order: 1. **Screens** (3 to 6 max) — name + 1-line purpose. 2. **Data model** — Room entities + DAOs. 3. **Permissions** — exactly what's needed + the Play Console justification. 4. **Play Store hooks** — name candidates (3), category, short description, screenshot story. 5. **Out of scope for v1** — 3 to 5 things I should NOT build first. Flag any Play Store policy risks (especially around background location, foreground services, and SMS/Call permissions). - 2Scaffold with CursorCursor
Cursor at the project root. Composer scaffolds screen-by-screen. Use Android Studio side-by-side for previews; the @Preview cycle is fast.
- 3Run on Emulator + a real deviceAndroid Studio
Android Studio: Pixel 9 emulator + at least one cheap real device (Samsung mid-range). Layout breakage on smaller / older devices is the most common Play Store quality complaint.
- 4Profile with Android VitalsAndroid Studio
Studio Profiler before release. The Play Console grades you on startup time, ANR rate, and battery — get them green before the first Play submission.
- 5Sign + uploadAndroid Studio
Build → Generate Signed Bundle → upload to Play Console as Internal testing first. Promote to Production after a few days of internal testing.
Solo dev built a niche utility app. Cursor handled the bulk of Compose code; Studio Profiler caught a startup regression that would have failed Android Vitals. Internal testing for 5 days, promoted to production at week 4. Initial install rate: 1.2k organic in month 1.
AI agents trained on older Android codebases sometimes default to XML. Re-prompt for Compose; mixing XML and Compose works but doubles the surface area.
Like Apple's nutrition labels, but more aggressive. Walk through every dependency with Claude before submitting. Mismatches between actual SDK behavior and the form get apps removed, not just rejected.
Studio's Gemini integration is fine for inline completions but doesn't reach Cursor's Composer or Claude Code for cross-file edits. Don't fight Gemini; treat it as a faster Tab key.