Build System Used for the Android App in AI Edge Gallery: Gradle with Kotlin DSL

The AI Edge Gallery Android app uses Gradle with Kotlin DSL as its build system, centralized through a version catalog (libs.versions.toml) and configured across settings.gradle.kts, build.gradle.kts, and app/build.gradle.kts to target SDK 35 with Jetpack Compose support.

The google-ai-edge/gallery repository contains the AI Edge Gallery application, an Android showcase for on-device machine learning models. Understanding the build system used for the Android app is essential for contributors who need to modify dependencies, update SDK versions, or adjust compile options. The project adopts modern Gradle practices using type-safe Kotlin DSL scripts and a centralized version catalog to maintain clean, maintainable build configuration.

Core Build System Architecture

The Android module utilizes Gradle with Kotlin DSL (*.gradle.kts files) rather than the legacy Groovy DSL. This architecture provides compile-time safety, superior IDE autocomplete, and seamless integration with Android Studio. The build logic is distributed across four primary files that handle plugin management, global conventions, module-specific Android settings, and dependency versioning.

Key Configuration Files

settings.gradle.kts (Plugin Management)

Located at Android/src/settings.gradle.kts, this file establishes the plugin repositories including Google Maven, Maven Central, and the Gradle Plugin Portal. It implements a resolutionStrategy that pins the OSS-Licenses plugin to version 0.10.6 (lines 17-35) and declares the root project name while including the :app module.

build.gradle.kts (Root Project)

The root Android/src/build.gradle.kts declares common plugins—including android.application, google.services, kotlin.android, kotlin.compose, hilt.application, and ksp—without applying them immediately. This pattern allows subprojects to selectively apply only the plugins they require.

app/build.gradle.kts (Module Configuration)

The Android/src/app/build.gradle.kts file contains the concrete Android build configuration. It defines:

• Namespace: com.google.ai.edge.gallery (lines 31-33)
• SDK Versions: compileSdk = 35, minSdk = 31, targetSdk = 35 (lines 33, 36-38)
• Version Metadata: versionCode = 23, versionName = "1.0.11" (lines 39-41)
• Compatibility: Java 11 source/targetCompatibility with jvmTarget = "11" for Kotlin 2.2 (lines 58-64)
• Build Features: compose = true and buildConfig = true (lines 66-68)

libs.versions.toml (Version Catalog)

The Android/src/gradle/libs.versions.toml file centralizes all dependency versions. Build scripts reference libraries via the libs accessor (e.g., implementation(libs.androidx.core.ktx)), decoupling version numbers from build logic.

Dependency Management with Version Catalogs

The project leverages Gradle's Version Catalog to prevent version fragmentation. To add a new dependency, first declare it in libs.versions.toml:

[versions]
someNewLib = "1.2.3"

[libraries]
some.new.library = { group = "com.example", name = "new-lib", version.ref = "someNewLib" }

Then reference it in app/build.gradle.kts:

dependencies {
    implementation(libs.androidx.compose.navigation)
    implementation(libs.some.new.library)
}

For temporary version overrides during command-line builds, use the -P flag:

./gradlew :app:assembleDebug -Pandroidx.core.ktx.version=1.16.0

Build Types and Signing Configuration

As implemented in app/build.gradle.kts (lines 52-56), the release build type currently references the debug signing configuration and disables code shrinking:

buildTypes {
    release {
        isMinifyEnabled = false
        signingConfig = signingConfigs.getByName("debug")
    }
}

To enable ProGuard and code shrinking for production releases, modify the block:

buildTypes {
    release {
        isMinifyEnabled = true
        proguardFiles(
            getDefaultProguardFile("proguard-android-optimize.txt"),
            "proguard-rules.pro"
        )
        signingConfig = signingConfigs.getByName("debug")
    }
}

Practical Build Commands

Execute standard Gradle tasks from the Android/src directory to build and install the application:

# Install debug variant on connected device

./gradlew :app:installDebug

# Assemble release APK (unsigned/with debug signing)

./gradlew :app:assembleRelease

# Clean build artifacts

./gradlew clean

Summary

• The AI Edge Gallery Android app uses Gradle with Kotlin DSL as its build system, configured across settings.gradle.kts, build.gradle.kts, and app/build.gradle.kts.
• SDK Versions: Targets API 35 with a minimum of API 31 (compileSdk = 35, minSdk = 31, targetSdk = 35).
• Version Catalog: Centralizes dependency management via gradle/libs.versions.toml and the libs accessor.
• Build Features: Enables Jetpack Compose, Build Config generation, Kotlin Symbol Processing (KSP), and Hilt for dependency injection.
• Signing Strategy: Uses debug signing configuration for release builds during development, with ProGuard (isMinifyEnabled) disabled by default.

Frequently Asked Questions

What build system does the AI Edge Gallery Android app use?

The Android app uses Gradle with Kotlin DSL (*.gradle.kts files) rather than Groovy. This modern configuration provides type-safe build scripts and is managed through a centralized version catalog located at gradle/libs.versions.toml, with plugin resolution logic defined in settings.gradle.kts.

Where are the SDK versions and application ID configured?

These settings reside in app/build.gradle.kts. According to the source code, the namespace is set to com.google.ai.edge.gallery (lines 31-33), with compileSdk at 35, minSdk at 31, targetSdk at 35, versionCode at 23, and versionName at "1.0.11" (lines 33-41).

How do I add a new dependency to the project?

First define the library and its version in gradle/libs.versions.toml under the [versions] and [libraries] sections. Then reference it in app/build.gradle.kts using the libs accessor, such as implementation(libs.some.new.library). This approach keeps version numbers centralized and out of the build scripts.

Why does the release build use the debug signing configuration?

As implemented in app/build.gradle.kts (lines 52-56), the release build type references signingConfigs.getByName("debug") and sets isMinifyEnabled to false. This configuration simplifies local testing by avoiding the need for release keystores and ProGuard mapping files during development, though production deployments should configure proper release signing and enable code shrinking.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}