release-readiness-workflow

Android Release Readiness Workflow

Purpose

Check whether an Android app or library is ready for release without starting a publish workflow by default.

The practical decision is which version, signing, packaging, policy, changelog, and automation surfaces must be verified before a human or repo-owned release system publishes artifacts.

Source Check

Use repo-local Gradle files, release docs, CI workflows, Fastlane files, checked-out automation sources, and Dash.app docsets opportunistically for exact Gradle or Java questions. Use official documentation as authority for Android-specific release, signing, privacy, permissions, and Play behavior:

• Prepare and roll out a release
• Android App Bundles
• Sign your app
• Shrink, obfuscate, and optimize your app
• Play Developer API
• Fastlane supply documentation

Translate documentation into concrete release files, commands, artifacts, and gates.

Inspection Workflow

1. Identify release ownership:
   • app module
   • release build type
   • product flavors
   • version code and version name
   • changelog or release notes
   • CI release workflow
   • Fastlane, Gradle Play Publisher, Play Developer Publishing API client, or custom scripts
2. Inspect signing boundaries:
   • signing config names
   • keystore references
   • environment variable names
   • secret-handling docs
   • local placeholder configs
3. Inspect packaging:
   • app bundle tasks
   • APK tasks
   • R8/ProGuard files
   • mapping output expectations
   • native debug symbols if present
4. Inspect policy-sensitive surfaces:
   • permissions
   • exported components
   • privacy disclosures
   • target SDK requirements
   • Play delivery tracks and rollout docs
5. Route automation:
   • identify the repo-owned release command or CI job
   • explain required credentials or approvals
   • stop before publish unless the user explicitly requested the publish action

Command Selection

Prefer dry, local, or artifact-building checks first:

./gradlew :app:lintRelease
./gradlew :app:assembleRelease
./gradlew :app:bundleRelease

Use repository-documented release commands when they exist. Treat commands that upload, promote, submit for review, or publish as explicit approval-gated actions.

Automation Routing

When a repository already owns release automation, report:

• automation owner: Gradle, CI, Fastlane, Play Developer Publishing API client, or custom script
• trigger: local command, CI workflow dispatch, tag, branch, or manual approval
• credentials: environment variable names or secret names, without printing secret values
• artifacts: AAB, APK, mapping file, native symbols, changelog, or release notes
• publish boundary: the exact command or click that would upload, promote, or release

Output Shape

Return:

1. Release surface: app or library module, variant, flavor, and artifact type.
2. Versioning: version code, version name, changelog, and policy status.
3. Signing: signing config, secret boundary, and local-safe checks.
4. Packaging: AAB, APK, R8/ProGuard, mapping, and symbol outputs.
5. Automation route: Gradle, CI, Fastlane, Play API, custom script, or none found.
6. Validation path: commands run or recommended.
7. Publish boundary: what was deliberately not run without explicit approval.

Guardrails

• Do not publish, upload, promote, submit for review, or change Play tracks by default.
• Do not print keystore passwords, service account keys, tokens, or signing secrets.
• Do not invent release automation when the repo has no release owner.
• Do not bump version code, version name, target SDK, or signing config without explaining the release impact.
• Do not remove R8/ProGuard rules or mapping outputs casually.