Declarative, Agent-Ready
Android Builds with Lightbuild

Kartik Arora

Lead Engineer @

GDE Android

kartikarora.me

Follow Along

Presentation QR

Presentation Slides

Codelab QR

Hands-on Codelab

Repository: github.com/kartikarora/ICanHazStream

Overview

build

1. Build Script Trade-offs

How imperative execution impacts IDE sync times and automated coding agents.

data_object

2. Lightbuild Architecture

Schema-validated YAML, app shell structure, and resolved.deps lockfiles.

account_tree

3. Migration: ICanHazStream

Converting an 8-module Compose app and verifying automated module scaffolding.

analytics

4. Status & Trade-offs

Sync benchmarks, agent edit reliability, and current evaluation scope.

Part 1: The Imperative Configuration Model

Analyzing configuration-time execution costs in multi-module Android codebases.

Executable Build Scripts

Gradle Configuration Phase Overhead

Configuration-Time Execution

  • Arbitrary JVM Code: Evaluates lambdas, plugins, and custom logic before any task runs.
  • Graph Recalculation: IDE sync requires running scripts across all modules to resolve dependencies.
  • Dynamic Version Resolution: Remote repository lookups on initial open or branch change.

Operational Impact

  • Sync Latency: Cold syncs take 30 to 60+ seconds in multi-module repositories.
  • Memory Footprint: Gradle daemons consume significant memory during configuration.
  • Maintenance: Composite builds and convention plugins require ongoing upkeep.

Automated Edits in Imperative Scripts

Common failure modes when AI coding agents modify Kotlin DSL build files:

error_outline

Syntax & Scoping Errors

Mismatched braces, misplaced plugins {} blocks, or version catalog syntax discrepancies fail configuration.

call_split

Side-Effect Dependency

Agents cannot easily evaluate conditional logic or plugin inheritance without running the script.

code

Token Overhead

Passing multi-file Gradle DSL scripts and classpaths consumes significant prompt token budget.

Part 2: Lightbuild Architecture

Google's declarative configuration layer for Android projects.

Transpilation Model

Lightbuild acts as a declarative frontend that compiles to Gradle and AGP instructions:

Lightbuild Architecture

Root Manifest: project.lightbuild.yaml

Combines repository definitions, module lists, and compiler toolchains into a single file:

project:
  name: ICanHazStream
  modules:
    - app
    - app-core
    - core/model
    - core/data
    - core/ui
    - feature/explore
    - feature/details

repositories:
  - google
  - mavenCentral

lightbuild:
  version: 0.0.30

build:
  java:
    version: 17
  kotlin:
    version: 2.4.20
    jvmTarget: "17"

Module Configuration: App Shell vs. Library

Application modules are thin assembly shells; actual code lives in app-core library:

app/lightbuild.yaml (Thin Shell)

module:
  type: application

android:
  namespace: me.kartikarora.icanhazstream
  applicationId: me.kartikarora.icanhazstream
  compileSdk: 36
  minSdk: 24
  targetSdk: 36

dependencies:
  - module: app-core

app-core/lightbuild.yaml (Library)

module:
  type: library

android:
  namespace: me.kartikarora.icanhazstream
  compileSdk: 36
  minSdk: 24

dependencies:
  - module: core/ui
  - module: core/data
  - module: feature/explore

Key Architecture Rule: Application modules in Lightbuild are empty shells without visibility into source code in app/src. All app entry points (MainActivity) must live in a library like app-core.

Dependency Locking: resolved.deps

Deterministic dependency tracking for Android builds:

lock

Pinned Transitive Tree

Stores exact versions for all direct and transitive dependencies per module.

speed

Offline Sync

Reads pinned dependencies from disk during IDE sync without querying remote repositories.

terminal

Managed by CLI

Regenerated by running lightbuild resolve. Committed to version control.

Part 3: Migration & Agent Workflow

Migrating ICanHazStream and executing automated module scaffolding.

Sample Application Architecture

ICanHazStream: 8-Module Jetpack Compose App

Module Dependency Graph

Agent Workflow Loop

Interaction pattern for AI coding tools in Lightbuild repositories:

Agent Workflow Loop

Live Walkthrough: Scaffolding a Module

Automating :feature:reviews Addition

terminal

Automated Scaffolding Steps

Prompt: "Add feature/reviews module with Compose M3 dependencies and wire it to app."

  • 1. Agent updates project.lightbuild.yaml and creates feature/reviews/lightbuild.yaml
  • 2. Run lightbuild resolve to update resolved.deps
  • 3. Run lightbuild build to compile target artifacts

Part 4: Metrics & Scope

Synchronization timings, agent reliability metrics, and evaluation scope.

Performance Comparison

~1.1s

IDE Project Sync

Static schema parsing versus 40+ seconds cold sync with composite convention plugins.

98%

Agent Edit Success

Deterministic data mutation prevents common Kotlin DSL syntax and scoping failures.

Zero

Configuration-Time JVM Logic

Eliminates JVM code execution during project structure discovery.

Adoption Considerations

Suitable Use Cases

  • New Applications: Greenfield projects and modern Compose codebases.
  • Workshops & Codelabs: Fast, reproducible project onboarding.
  • Agentic Workflows: Automated feature scaffolding and dependency management.
  • Prototypes: Quick validation of modular layouts.

Keep Kotlin DSL

  • Custom Build Logic: Projects with bespoke Gradle tasks or bytecode manipulation.
  • Complex Release Pipelines: Custom signing or publishing plugins.
  • Large Production Monorepos: Codebases dependent on enterprise Gradle infrastructure.

References & Resources

Primary Sources:

menu_book Open Codelab

FIN.

Thank you.

Kartik Arora

kartikarora.me