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

> Discover the Gradle Kotlin DSL build system powering the Google AI Edge Gallery Android app. Learn about its centralized configuration, version catalog, and SDK 35 Jetpack Compose setup.

- Repository: [google-ai-edge/gallery](https://github.com/google-ai-edge/gallery)
- Tags: internals
- Published: 2026-04-06

---

**The AI Edge Gallery Android app uses Gradle with Kotlin DSL as its build system, centralized through a version catalog ([`libs.versions.toml`](https://github.com/google-ai-edge/gallery/blob/main/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`](https://github.com/google-ai-edge/gallery/blob/main/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`](https://github.com/google-ai-edge/gallery/blob/main/libs.versions.toml):

```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`:

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

```

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

```bash
./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:

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

```

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

```kotlin
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:

```bash

# 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`](https://github.com/google-ai-edge/gallery/blob/main/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`](https://github.com/google-ai-edge/gallery/blob/main/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`](https://github.com/google-ai-edge/gallery/blob/main/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.