Before AI Studio's Gradle and AGP Versions Quietly Break Your Existing App

A gate that inspects generated declarations at the import boundary

Pinning the config alone is not enough: if whoever copies the generated code accidentally leaves an inline dependency, the same accident recurs. So turn the import from "a manual copy" into "only a diff that passes inspection gets in." I place the output in a staging folder, run an inspection script against it, and only then move it into the main tree — a two-stage approach.

#!/usr/bin/env bash
# import_gate.sh — inspection gate before importing AI Studio output into the main tree
# usage: ./import_gate.sh path/to/generated_module
set -euo pipefail
 
SRC="$1"
VIOLATIONS=0
 
# (1) detect versioned dependencies inline-declared in build.gradle
#     e.g. implementation("androidx.foo:bar:1.2.3") — a declaration with :version
if grep -REn 'implementation\("[^"]+:[^"]+:[0-9]' "$SRC" 2>/dev/null; then
  echo "Inline versioned dependency found. Replace with a libs.versions.toml alias reference"
  VIOLATIONS=$((VIOLATIONS+1))
fi
 
# (2) does the output declare AGP / Kotlin / minSdk on its own?
for KEY in 'com.android.application' 'org.jetbrains.kotlin' 'minSdk' 'compileSdk'; do
  if grep -REn "$KEY[^a-zA-Z].*[0-9]+\.[0-9]" "$SRC" 2>/dev/null | grep -v 'libs\.'; then
    echo "The output declares $KEY directly (violates the catalog single source of truth)"
    VIOLATIONS=$((VIOLATIONS+1))
  fi
done
 
# (3) does it use APIs that require desugaring (java.time, etc.)? if so, the main side must enable desugar
if grep -REn 'import java\.time\.' "$SRC" 2>/dev/null; then
  echo "Uses java.time. minSdk 23 requires desugaring (confirm the main module enables it)"
fi
 
if [ "$VIOLATIONS" -gt 0 ]; then
  echo "Stopped: ${VIOLATIONS} violation(s). Fix the output and re-run."
  exit 1
fi
echo "Import gate passed. Safe to merge into the main tree."

You can run this script in CI, and you can hand it to an agent as a rule: "always pass the import through import_gate.sh first." Inserting the same kind of inspection before a push via an Antigravity hook is contiguous with a design that derives the upload numbering from a single source of truth; importing generated artifacts sits on that same line.

Gradle's last line of defense — fail the build on unintended bumps

Even if something slips past the script, you can keep a safety net that detects "a version that must not rise, rose" as a build failure during Gradle's resolution stage. Pin the critical dependencies with resolutionStrategy and fail when they drift.

// applied to all modules, e.g. in settings.gradle.kts
configurations.all {
    resolutionStrategy {
        // explicitly lock dependencies you don't want quietly bumped on import
        force("com.android.tools:desugar_jdk_libs:2.1.5")
        // fail if a version changes dynamically during resolution
        failOnVersionConflict()
    }
}

With failOnVersionConflict() in place, the build stops the instant a transitive dependency the output dragged along conflicts with an existing one. It feels noisy at first, but "noticing at the build right after the merge" is orders of magnitude cheaper than "noticing via a crash after release" — that is my honest takeaway from running staged rollouts again and again.

Decide on three layers up front

The machinery above is sturdiest when you stack it as three layers with distinct roles.

1. Catalog layer: concentrate version declarations in one place, gradle/libs.versions.toml, and let modules reference only aliases
2. Inspection layer: with import_gate.sh, reject inline dependencies and any standalone AGP/minSdk declarations the output wrote, before import
3. Resolution layer: with failOnVersionConflict(), stop any transitive drift that slipped through as a build failure

In staged-rollout terms, before and after adding these three layers I judge success by whether I can hold Crash-free users at 99.7% or higher and ANR under 0.20%. If those two numbers hold on a release that mixed in generated screens, I treat the import as having been safe.

Three things to always check after import

Even once it passes the gate and merges, output-specific oversights can surface in production. These are the three I check every time.

For the third point, I summarized the triage lens for validating generated Compose before it ships in the verification gate that closes the green-in-emulator, broken-on-device gap. Pulled along by the speed of generation, skipping this device check comes back as a post-release crash.

How much to delegate to generation, and what to hold yourself

Running solo for a long time means rethinking "how much to delegate" each time a new generation tool arrives. AI Studio's Kotlin/Compose generation is plainly strong for prototyping screens and confirming the shipping path. But the build's foundation — the single source of truth for versions alone — is something I do not hand over to the generation side. That is the line I currently hold. Receive the output strictly as "a proposal for a new screen," and keep the responsibility for landing it into the existing constellation on the human side. The version catalog and the import gate are tools for fixing that line as a mechanism.

If you want to start moving, first consolidate your running app's version declarations into gradle/libs.versions.toml and add the single line failOnVersionConflict(). Before you import any output, whether your own footing is already a single source of truth — that is the first fork in the road.