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

1. Inspect signing boundaries:

• signing config names
• keystore references
• environment variable names
• secret-handling docs
• local placeholder configs

1. Inspect packaging:

• app bundle tasks
• APK tasks
• R8/ProGuard files
• mapping output expectations
• native debug symbols if present

1. Inspect policy-sensitive surfaces:

• permissions
• exported components
• privacy disclosures
• target SDK requirements
• Play delivery tracks and rollout docs

1. 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.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: gaelic-ghost
• Source: gaelic-ghost/socket
• License: Apache-2.0

Install and usage instructions live in the source repository linked above.