Android Build Automation Setup
By default, Gradle runs everything single-threaded. On projects with 15+ modules, cold builds take 4–7 minutes, incremental—90 seconds. In CI this becomes a queue blocking review. Build automation is not about "button in pipeline" but Gradle working predictably on any machine and producing signed AAB without manual steps.
Key Pain Points in Android Build Automation
Most common—APK/AAB signing in CI. Developers store keystore in repository (bad) or pass via command line in plain text (worse). Correct scheme: keystore Base64-encoded, in CI variable, decode to temporary file before build, delete after. In build.gradle.kts:
android {
signingConfigs {
create("release") {
storeFile = file(System.getenv("KEYSTORE_PATH") ?: "debug.keystore")
storePassword = System.getenv("KEYSTORE_PASSWORD") ?: "android"
keyAlias = System.getenv("KEY_ALIAS") ?: "androiddebugkey"
keyPassword = System.getenv("KEY_PASSWORD") ?: "android"
}
}
buildTypes {
release {
signingConfig = signingConfigs.getByName("release")
isMinifyEnabled = true
proguardFiles(getDefaultProguardFile("proguard-android-optimize.txt"), "proguard-rules.pro")
}
}
}
Build configuration by branch—second pain point. main → release AAB for Play Store, develop → debug APK with test endpoints, release/* → staging APK for QA. Implemented via buildFlavors + CI conditions, not separate build.gradle per environment.
Gradle caching in CI—separate story. Without cache, 200–400 MB dependencies download each time. With proper ~/.gradle/caches and ~/.gradle/wrapper caching—first build after build.gradle change takes full time, rest—incremental.
How We Set Up
Base stack: Gradle 8.x + AGP (Android Gradle Plugin) 8.x + GitHub Actions / GitLab CI / Bitrise. Fastlane for tasks Gradle can't handle: Google Play upload via supply, notifications, track management (internal → alpha → production).
Typical CI pipeline structure:
# .github/workflows/android-release.yml
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-java@v4
with:
java-version: '17'
distribution: 'temurin'
- name: Cache Gradle
uses: actions/cache@v4
with:
path: |
~/.gradle/caches
~/.gradle/wrapper
key: gradle-${{ hashFiles('**/*.gradle*', '**/gradle-wrapper.properties') }}
- name: Decode Keystore
run: echo "$KEYSTORE_BASE64" | base64 -d > app/release.keystore
env:
KEYSTORE_BASE64: ${{ secrets.KEYSTORE_BASE64 }}
- name: Build Release AAB
run: ./gradlew bundleRelease
env:
KEYSTORE_PATH: release.keystore
KEYSTORE_PASSWORD: ${{ secrets.KEYSTORE_PASSWORD }}
KEY_ALIAS: ${{ secrets.KEY_ALIAS }}
KEY_PASSWORD: ${{ secrets.KEY_PASSWORD }}
- name: Upload Artifact
uses: actions/upload-artifact@v4
with:
name: release-aab
path: app/build/outputs/bundle/release/app-release.aab
Separately configure gradle.properties for CI: org.gradle.daemon=false (daemon not needed in CI), org.gradle.parallel=true, org.gradle.configureondemand=true. On projects with multiple modules this noticeably reduces configuration time.
Parallel Tasks and Optimization
Monolithic projects see little parallelization benefit. But modular architecture (:core, :feature-auth, :feature-feed, :app)—Gradle builds dependency graph and compiles independent modules in parallel. ./gradlew assembleDebug --parallel on 8-core agent gives noticeable boost.
For large teams, Gradle Build Cache makes sense—either Remote Build Cache via Gradle Enterprise (paid), or via build-cache plugin with S3 backend (open solution). Repeated tasks taken from cache, not recalculated.
Workflow
Audit current build.gradle → migrate to build.gradle.kts (if Groovy DSL) → setup signing config via environment variables → write CI configuration → setup caching → test on multiple branches → document for team.
Cost calculated individually. Timeline: 2–3 days for typical single-module project, up to 5 for multi-module with non-standard pipeline requirements.