Works with the AI Agents you already use

    Claude CodeClaude CodeCursorCursorCodex CLICodex CLIMuseMuseDotsDots+21 more

    Android Release Pipeline: CLI build, sign, verify, ship APK

    1

    CLI-only Android release chain: version-matrix doctor, three-way artifact consistency check, atomic upload, in-app update contract.

    $5

    Secure checkout via Stripe

    Money-back guarantee

    Converts to your local currency at checkout

    Security scanned
    Android Release Pipeline: CLI build, sign, verify, ship APK

    Android Release Pipeline: CLI build, sign, verify, ship APK

    Example session with this skill installed

    Gradle says BUILD SUCCESSFUL but testers report the 3.7.1 APK installs on Android 13 and refuses on Android 15. Last time the file I uploaded to my CDN also wasn't the one I tested. Check the toolchain and the artifact before I ship this one.

    • Read your context and instructions
    • Compiled the android release pipeline

    Summary

    Three separate faults, none of them in the Kotlin source. The build succeeds because Gradle never validates the AGP / compileSdk / targetSdk triangle — it just compiles against a platform it was not told to support.

    Real run of doctor.py -p ~/apps/shop-companion --require apk (paths shortened to ~ / $ANDROID_HOME; every [ OK ] / [WARN] / [FAIL] line is verbatim):

    [ OK ] JDK                   21.0.2 ($JAVA_HOME, from scan of common directories)
    [ OK ] Android SDK           $ANDROID_HOME (from scan of common directories)
    [INFO] Platforms installed   35
    [INFO] build-tools           34.0.0, 35.0.0
    [ OK ] cmdline-tools         in place (sdkmanager / apkanalyzer available)
    [ OK ] Gradle Wrapper        wrapper points at 8.2
    [INFO] Mirror hint           The official source services.gradle.org easily times out or drops in China (a failed download leaves a *.part behind). You can switch to mirrors.cloud.tencent.com/gradle/.
    [INFO] Main module           app
    [ OK ] AGP                   8.1.0
    [ OK ] Kotlin                1.9.0
    [ OK ] AGP <-> Gradle        AGP 8.1.0 + Gradle 8.2 match
    [WARN] compileSdk            compileSdk 35 is past the officially supported range of AGP 8.1.0 (<=34)
    [ OK ] AGP <-> JDK           JDK 21 meets the floor of AGP 8.1.0 (>= 17)
    [FAIL] targetSdk             targetSdk 35 is below the current Play floor 36 -> the submission or update is rejected outright by Play Console (the build stage gives no hint of it)
    [ OK ] compileSdk platform   android-35 is installed
    [FAIL] Signing               There is a signingConfigs block, but it does not read key.properties and no key file was found.
    [FAIL] Target artifact       You asked for apk, but there is no key.properties -> generate a key with keytool first
    
    Verdict: **cannot build** - 3 ERROR(s), 1 WARN(s). Fix the ERRORs first.
    Project summary: com.example.shop  versionName=? versionCode=42  compileSdk=35 minSdk=24 targetSdk=35
    
    Symptom you reportedWhat the check actually foundWhere it is decided
    Installs on 13, refused on 15AGP 8.1.0 officially supports compileSdk <= 34, but compileSdk 35 is set. It compiles, so BUILD SUCCESSFUL is truthful, but the artifact is built against an unsupported platformapp/build.gradle android.compileSdk
    versionName=?The module parser could not resolve versionName — the release manifest will carry a wrong version and the in-app update contract breaks silentlydefaultConfig.versionName
    Wrong file on the CDN last timeNo key.properties, so the release signing config falls back to the debug key; that APK has a different signature and the same can silently change the artifact bytes between what you tested and what you uploadedandroid.signingConfigs.release

    Fix order (do not reorder these)

    1. compileSdk 35 -> 34,

    or bump AGP to a version that officially supports 35. Do not do both at once — you will not know which one fixed it.
    2. Add key.properties with storeFile / storePassword / keyAlias / keyPassword, and read it from signingConfigs.release.
    3. targetSdk 35 -> 36 (Play Console rejects below 36 outright; the build stage gives no hint).
    4. Re-run doctor.py --require apk, then build, then verify_release.py to compare APK bytes vs release.json vs the SHA-256 you publish.

    Next step

    python scripts/doctor.py -p ~/apps/shop-companion --require apk   # must print Verdict: can build
    ./scripts/build_android.sh release
    python scripts/verify_release.py --apk app/build/outputs/apk/release/app-release.apk --manifest release.json
    

    verify_release.py is the one that answers your second question: it refuses to pass when the three-way consistency check (APK bytes vs release manifest vs published hash) disagrees, so the file on the CDN is the file you tested.

    Connects securely to your tools. The creator never sees your data.

    About this skill

    You do not need Android Studio to ship an APK. You do need to know why the last release failed, and the answer is almost never in the code.

    This skill encodes the checks that catch most release disasters before a user sees them: (1) an AGP / Gradle / JDK / compileSdk compatibility check that runs before any build, because a mismatched toolchain happily produces BUILD SUCCESSFUL and an uninstallable artifact; (2) a three-way consistency check (APK bytes vs the release manifest vs the file hash) so the thing you uploaded is the thing you tested; (3) an atomic multi-directory upload with a dry run first, plus the in-app update contract that decides whether existing users can actually upgrade.

    Includes a build script, a doctor and a verifier (standard-library Python where possible), a 13-entry failure library keyed by exact exit code and fix, and a version matrix reference.

    What it does not do: no developer account registration, no store publishing, no signing keys (the template ships placeholders only). It promises no store approval, only that artifacts are consistent, installable and upgradable.

    Focuses on self-hosted distribution only. No Google Play Store listing or policy management. Requires manual setup of key.properties for signing.

    How to use

    1. 1

      Connect your agent to the Agensi MCP

      Copy the prompt and paste it into Claude, ChatGPT, Cursor or any agent that supports MCP. It sets up the connection for you. Manual setup

    2. 2

      Sign in to Agensi

      Your agent shows a sign-in link. Sign in and click Allow.

    3. 3

      Ask for what you need

      Your agent loads this skill and uses it on your task. It always asks before any payment.

    Reviews

    No reviews yet

    Be one of the first to try it. Every listed skill goes through the trust checks below.

    Security scanned

    Checked by our 8-point scan before listing

    Fresh listing

    Recently published to Agensi

    Money-back guarantee

    Doesn't do what its page promises? You get your money back.

    Trust & safety

    Security scan

    Security scan passed 8 days ago

    Requires

    Python 3.8+ (stdlib only)
    bash / POSIX shell
    Android SDK + platform-tools
    JDK 17 or newer
    Gradle (wrapper or global)
    Python
    macOS

    Permissions

    Terminal / Shell
    Network Access
    Read Files
    Write Files
    Environment Variables

    Terminal is required because every check is a command that must run on the machine holding the project (gradle -v, sdkmanager --list, keytool -list). Read Files covers settings.gradle, app/build.gradle, gradle-wrapper.properties and release.json. Write Files is only used to write the release manifest and the verification report; the scripts never touch source code. Network is used only to resolve the toolchain version table and is optional. No credentials are read: key.properties passwords are never parsed or printed.

    Listed8 days ago
    Updated6 days ago

    What's inside

    Frequently Asked Questions

    This skill automates the entire Android build lifecycle—from environment auditing to signing and distribution—without needing Android Studio, specifically solving common 'App not installed' errors caused by incorrect signature schemes or version mismatches.

    You will receive a suite of specialized scripts including a diagnostic auditor, an automated build runner, a signature verifier, and a distribution script, along with a compatibility matrix for Gradle and AGP.

    Yes, the pipeline is designed for headless servers and CI/CD environments; it uses the command-line interface (CLI) to handle builds, signing, and artifact verification without a GUI.

    The skill uses a dedicated audit script (doctor.py) to scan your environment and ensure your JDK, Gradle, and Android Gradle Plugin versions are compatible before a build even starts.

    No, this skill focuses on the technical build and self-distribution process; it does not include tools for managing Google Play Store metadata, screenshots, or store policy compliance.

    It is compatible with standard Android projects using Gradle and the Android Gradle Plugin, and can be integrated into most AI agent workflows that support shell execution and Python scripts.