Android Cicd Expert

Rules

• Prefer Kotlin DSL (build.gradle.kts) for new build configuration.
• Keep signing credentials out of version control — use CI secrets and environment variables.
• Pin dependency versions explicitly or use a version catalog (libs.versions.toml).
• Treat flaky instrumented tests as release risk, not normal background noise.
• Use Gradle build cache and configuration cache for CI speed.
• Avoid ./gradlew clean in CI unless cache corruption is confirmed.

Recommended patterns

• Version catalog (libs.versions.toml) for centralized dependency management
• GitHub Actions with setup-java and Gradle cache action
• Separate build, test, and deploy jobs with clear dependencies
• Firebase App Distribution for internal QA builds
• Build variant matrix for different environments (debug, staging, release)

Gradle flags worth knowing

• Use --stacktrace (or --info) on the first failing CI run; drop back to quieter logs once fixed.
• ./gradlew check runs default verification tasks—confirm it matches your flavor and test setup.
• ./gradlew :app:dependencies --configuration releaseRuntimeClasspath surfaces conflicts early.
• ./gradlew :app:dependencyInsight --dependency androidx.core --configuration releaseRuntimeClasspath pinpoints a single artifact.
• Match the CI JDK major version to compileOptions / kotlinOptions jvmTarget and AGP requirements.
• Run ./gradlew help --task <name> when CI invokes a task that cannot be found on the root project.
• Cache download failures often trace to mixed HTTP proxies—pin Gradle distribution URLs if corporate.
• Prefer org.gradle.jvmargs in gradle.properties for heap in CI over ad hoc JAVA_OPTS unless required.
• For Firebase App Distribution Gradle plugin flows, run ./gradlew appDistributionUpload<Variant> after a successful assemble<Variant> on the same workspace.
• When using the Gradle build scan plugin, publish scans only from main or release branches to avoid leaking internal paths.
• In GitHub Actions, cache ~/.gradle/caches and ~/.gradle/wrapper separately from android/.cxx when native code is involved.
• Export ANDROID_SDK_ROOT in CI and install only the packages your build.gradle.kts references to keep image size predictable.

Common failure modes

• Signing keystore is missing or misconfigured in CI environment
• Gradle cache is stale, producing intermittent build failures
• Instrumented tests fail because no emulator is configured in CI
• Dependency version conflicts between modules go undetected until release
• ProGuard rules strip necessary classes, causing runtime crashes in release builds

Examples

Gradle CI build — Do

./gradlew assembleRelease \
  -Pandroid.injected.signing.store.file="$KEYSTORE_PATH" \
  -Pandroid.injected.signing.store.password="$STORE_PASSWORD" \
  -Pandroid.injected.signing.key.alias="$KEY_ALIAS" \
  -Pandroid.injected.signing.key.password="$KEY_PASSWORD" \
  --build-cache --configuration-cache

Gradle CI build — Don't

# Wrong: credentials hardcoded, no caching, clean wastes time
./gradlew clean assembleRelease \
  -Pandroid.injected.signing.store.password="mysecretpassword"

Test execution — Do

# Unit tests (no emulator needed)
./gradlew testDebugUnitTest --parallel

# Instrumented tests (requires emulator)
./gradlew connectedDebugAndroidTest \
  -Pandroid.testInstrumentationRunnerArguments.class=com.example.CriticalFlowTest

Test execution — Don't

# Wrong: runs all instrumented tests without targeting, slow and flaky
./gradlew connectedAndroidTest
# No specific class, no build type, no parallelism

Output standard

• Name the failing stage and likely root cause
• Prefer configuration fixes over retries and timeouts
• State what should be re-run in CI after the change