◆ Sparround

Gradle, build variants, signing & release

Gradle is the build system: dependencies, compilation, R8, signing, packaging. Concepts you must know:

  • Build types — debug/release: optimization, signing, debuggable differences
  • Product flavors — variants of the same code: dev/staging/prod (different API URLs), sometimes retail/corporate. Build type × flavor = a build variant (prodRelease)
  • buildConfigField / resValue — per-variant configuration (API URLs); secrets never go here — BuildConfig reads out of the APK
  • Version catalogs (libs.versions.toml) — centralized dependency management

Signing: APK/AABs are signed with the release keystore — lose it and you cannot ship updates on Play (Play App Signing softens this: Google holds the app signing key, you use an upload key — resettable if lost).

AAB (Android App Bundle) — the Play upload format: Google generates per-device optimized APKs (split by language, screen density, ABI) → smaller downloads. Mandatory for new Play apps.

The release flow: internal testing → closed/open testing → staged rollout (5% → 20% → 100%, watching vitals) → full release. The banking addition: a security checklist per release + pen-test cycles.

kotlin
android {
    flavorDimensions += "env"
    productFlavors {
        create("dev") {
            dimension = "env"
            applicationIdSuffix = ".dev"          // eyni cihazda yan-yana
            buildConfigField("String", "API_BASE", "\"https://api-dev.bank.example/\"")
        }
        create("prod") {
            dimension = "env"
            buildConfigField("String", "API_BASE", "\"https://api.bank.example/\"")
        }
    }
    buildTypes {
        release {
            isMinifyEnabled = true
            signingConfig = signingConfigs.getByName("release")
            // keystore parolları CI secret-lərindən gəlir,
            // heç vaxt repo-da saxlanmır
        }
    }
}

Flavors and variant configuration (build.gradle.kts)

CI/CD question prep: the typical pipeline — PR: lint + detekt + unit tests; merge: assemble + integration tests; release tag: AAB build (signing via CI secrets) → auto-upload to the Play internal track → QA approval → staged rollout. Tools: GitHub Actions/GitLab CI + Gradle Play Publisher/fastlane. "How do you roll back?" — Android has no rolling back to a previous version: halt the rollout + hotfix forward, which is why staged rollouts + feature flags are critical.

🛠 Practice task

Get your hands on the build configuration:

  • Add dev/prod flavors: different API_BASE, and install both side by side via applicationIdSuffix.
  • Set up a signing config for the release variant (with a test keystore) and build an AAB (bundleProdRelease).
  • Locate mapping.txt and write one sentence on why it matters.

Done when: both copies run side by side on the device and the AAB builds successfully.

📚 Sources and documentation