/android-app-factory

name: android-app-factory
description: "Suede AI Android app factory: plan, build, test, and prepare a production native Android app from product idea to a Play-ready signed bundle. Use for requests to create, ship, monetize, or modernize an Android app. Covers Kotlin and Jetpack Compose architecture, live target-API and Play policy checks, 16 KB page sizes, accessibility, privacy and Data Safety, Play Billing Library 8+, Play Integrity, account deletion, kids and Families rules, testing, performance, store assets, signing, and a release evidence gate. NOT FOR: uploading, promoting, or rolling out a build on Play (use suede-play-release); turning a website into an iOS app (use site-to-ios-app); a review-only pass on an existing app (use suede-code --findings-only); Play listing, keyword, and screenshot strategy (use suede-aso)."

Android App Factory

Iron Law: no release-ready claim without a signed `bundleRelease` plus a live
Play Console check, not a debug build, screenshot, source read, or upload.

Gate policy

Every check and verdict here is advice to the user, not a control on the agent. Run the checks, report results honestly, and complete what the user asked. A failed gate changes the report, never the work. The one exception: a finding that risks data loss, credential exposure, a legal or rights violation, a payment mistake, or irreversible public damage. Pause, name the risk, give the options, and let the user choose.

Principle

Build the product, policy evidence, and Play listing together. A successful release is an installable and usable app whose claims, disclosures, entitlements, privacy behavior, and store configuration agree.

Source Truth and Freshness

At the start of every release-oriented run:

1. Identify the exact repo, package/application ID, branch, Play app, target track, and whether the checkout is dirty. 2. Read `references/play-policy-baseline.md`. 3. Re-open the linked official Google sources for any submission-sensitive requirement. Record the URL, observed requirement, and check time in `assets/android-release-gate.template.md`. 4. Treat current repo code and the live Play Console as source truth for the app. Treat the reference date as a baseline, not permanent policy.

Take the target-SDK default and enforcement dates from the baseline file, never from memory. As of the 2026-10-23 baseline, phone and tablet submissions must target API 36 (extensions end 2026-11-01) and use Play Billing Library 8 or later. Recheck every run: form-factor exceptions and dates differ, and Google announces the next year's level each spring.

Delivery Contract

Lock these before implementation:

• user and one core outcome;
• supported form factors, devices, locales, minimum SDK, and offline behavior;
• application ID, ownership, signing model, Play app/track, and release owner;
• data inventory, third-party SDKs, permissions, account model, deletion path,

privacy policy owner, and Data Safety owner;

• monetization and entitlement source truth, or an explicit free-v1 decision;
• architecture and migration constraints;
• acceptance devices/API levels, tests, performance/accessibility targets,

store artifacts, and release evidence;

• external mutations requiring confirmation: product creation, credential use,

Play upload, track promotion, staged rollout, or production release.

Unknowns stay unknown. Never invent a package name, product ID, policy answer, privacy URL, customer claim, or Play Console state.

Production Pipeline

1. **Validate the product**: define the user outcome and evidence of demand. Treat keyword research as one input, not proof of product-market fit. 2. **Verify policy**: capture current target-SDK and form-factor rules, app access requirements, Data Safety scope, content rating, account deletion, billing policy, and any permission-specific declarations. 3. **Design architecture and risk**: use the smallest maintainable architecture that preserves unidirectional state, lifecycle safety, offline/error/loading states, test seams, and a least-data/least-permission posture. 4. **Scaffold**: native Kotlin + Jetpack Compose by default. Resolve current stable Android/Jetpack versions from official sources, lock them in a version catalog, and prove a debug build before feature work. 5. **Build the core loop**: implement one complete user outcome with real or deterministic demo data. Add history, saved state, sync, or accounts only when the product contract requires them. 6. **Prove quality**: unit, repository, ViewModel, Compose UI/instrumented, accessibility, and end-to-end core-loop tests as applicable; static analysis, release build, device/API matrix, baseline profile, and Macrobenchmark. 7. **Add monetization safely**: use Play Billing for covered digital goods, process pending purchases, verify and acknowledge purchases after entitlement handling, restore ownership, and keep secrets/server verification off-device. 8. **Complete trust surfaces**: privacy policy, Data Safety, SDK data behavior, permission rationale, in-app and web account deletion when accounts exist, content rating, ads declarations, app access instructions, and Play Integrity only where abuse risk justifies it. 9. **Build store artifacts**: truthful listing, icon/feature graphic, screenshots for every declared form factor, localization, support contact, release notes, and reviewer instructions. Route title, short description, keyword coverage, and screenshot sequencing to `suede-aso`; a listing that passes review but cannot be found ships nothing. 10. **Hand off to release**: signed AAB, Play App Signing, completed release gate, then `suede-play-release` for credential preflight, testing-track upload, promotion, staged rollout, and the live track readback.

Read these before building:

• `references/android-factory-pipeline.md`: phase artifacts and release flow;
• `references/