Lightbuild: A Declarative Android Build Built for AI Agents

From Executable Scripts to Static Data: A New Approach to Android Builds

In a joint presentation by Juan Sebastián Oviedo, Product Manager on the Android Developer Experience team, and Scott Meyers, Developer Relations Engineer, Google unveiled Lightbuild—an experimental Android build experience. It attempts to answer a fundamental question: what if project configuration were redesigned from scratch?

Today, Gradle and AGP form a dynamic system that underpins the build configuration of millions of production apps. Because build files are written in an imperative, Turing-complete language, the only general way for an IDE to understand project configuration is to execute the build scripts. Every time you open a project, switch branches, or edit a build file, the IDE must go through the configuration phase, execute plugin logic, build the project model, and only then can it offer features like code completion and navigation.

As Juan put it: "As a developer, what you care about most is shipping a great app, but managing build scripts, keeping AGP up to date, and keeping your project in sync with the IDE consumes a great deal of time and effort."

Declarative Configuration: Readable by Both Humans and Agents

The first pillar of Lightbuild is a declarative syntax. Compare the files on the left and right of the screen: a traditional build file is imperative code that can contain local variables, custom helper function calls, conditional statements, and inline task definitions; a Lightbuild configuration file, by contrast, is purely declarative data—no variables, no function calls, no conditional logic, just a clear statement of module type, SDK targets, and dependencies.

"If a new engineer joins the team and opens this file, they have no custom build idioms to decipher—every Lightbuild module uses the same, immediately readable language," Juan explained.

This separation is already a huge improvement for human readability, but it is even more transformative for agent-assisted workflows. When developers bring AI agents into their workflows, agents need to be able to read and modify build configuration, but they cannot predict the side effects of configuration changes—unless they actually build the project. In Lightbuild, project configuration is a deterministic static data graph. Agents can inspect this graph, understand the model topology, and modify it using known patterns: view the module list, dependencies and their versions, update dependencies, or even add an entirely new feature module—simply by reading and writing structured data.

Another key detail: Lightbuild is not a plugin of the build system, but an interface to the build engine. The current preview still uses Gradle as the execution engine under the hood, but the architecture lets Android Studio treat the project as a Lightbuild project.

Turing-complete language refers to a programming language with capabilities such as branching, loops, and variable assignment that can, in theory, express any computational process. The Groovy and Kotlin DSLs used by Gradle are both Turing-complete, which means build scripts can contain arbitrary logic, and an IDE cannot exhaustively determine their behavior through static analysis—it can only learn the final configuration result by actually executing them. This is precisely the root cause of slow and unpredictable synchronization in traditional Android projects. Declarative configuration gives up Turing completeness, using a restricted, structured data format (such as YAML) to describe "what" rather than "how," thereby making static analysis, formal verification, and machine reading possible.

Fast IDE Sync: Skipping Script Evaluation

The second pillar is developer productivity and flow. Because project configuration is a deterministic static data graph, the IDE can understand the project without executing the script evaluation phase or plugin code. Whether you are opening a project, editing a build file, or switching branches, the IDE can process the information quickly, letting you get straight to your tools.

Scott demonstrated an intuitive example: deleting a module in project.lightbuild.yaml at the project root makes the module disappear from the project the moment you save; undoing the change and saving brings it back immediately. "This is the fast IDE sync that Lightbuild delivers," Scott said.

This speed and reliability stem from how Lightbuild handles dependencies. Normally, after declaring a dependency, the build system must traverse the transitive dependency tree to collect version information and resolve conflicts. In Lightbuild, whenever dependencies change, the tool automatically computes transitive dependency information and writes it to a resolve.deps file in each module directory. This way, the IDE and build tools do not need to recompute when opening the project or rebuilding in the future. The team recommends checking these files into source control so that teammates can see changes in transitive dependency information during review, while also ensuring that local and CI pipelines use the same dependency versions.

resolve.deps also has a locked mode: with the --locked-dependencies flag, the tool compares the file contents against the declared dependencies and fails the build if there is any difference. This lets these files act like lock files, ensuring that dependencies do not change unexpectedly in CI/CD production builds.

Transitive dependencies are the libraries that a project's directly declared dependencies themselves depend on. For example, if you declare a dependency on A, and A depends on B and C, and B depends on some version of C, the build system must traverse the entire dependency tree, collect all version constraints, and resolve conflicts (such as choosing the highest version) to determine the final set of libraries to use. In large projects this process can involve hundreds of nodes, and it must be recomputed every time configuration changes—one of the main sources of slow Gradle sync. Lightbuild freezes the computed results into resolve.deps files, effectively caching the dynamic resolution results as static data and skipping repeated traversal.

A CLI Designed for AI Agents

Lightbuild is available in early preview in Android Studio Canary and as a standalone CLI tool. Scott created a demo project using the android create command with the empty activity Lightbuild template, and demonstrated the CLI's key commands:

• build, clean, test: standard build operations
• resolve: generates the resolve.deps files
• query: queries the project structure, helping developers and agents understand the project layout

The query command can list all buildable targets under a module (debug and release APKs and AABs) and supports a JSON output format—"which is much easier for your agent to consume," Scott noted. The output command shows the location of all binaries produced by the build. Meanwhile, the CLI includes a complete built-in help system that gives agents a detailed list of all arguments and subcommands.

AI Agent refers to an AI system that can autonomously perceive its environment, invoke tools, and execute multi-step tasks to achieve goals—for example, a coding assistant that can read code, modify files, and run commands. Unlike single-turn Q&A, an agent needs to reliably understand the current state of the object it is operating on and predict the consequences of its actions. For build configuration, the side effects of imperative scripts are hard to predict, so agents can only proceed by "trial and error"; a structured data graph, by contrast, lets agents read the topology through a query interface, modify it in patterned ways, and verify through build results, significantly reducing the risk and uncertainty of agents operating on the build system.

Project Structure: App Modules Are Empty Shells

The Lightbuild project structure has several unique aspects. The root project.lightbuild.yaml defines global settings: project name, module list, external repositories, and global versions. Each module has its own lightbuild.yaml.

Every Lightbuild project has at least two modules: an app module and a library module. The app module contains no source code—"because app modules do not change often, but builds take time. If you put all your app code in library modules, every build will be faster because there is no need to recompute and repackage everything in the app module," Scott explained.

This design also supports multiple app variants. In the Now in Android project demonstrated, demo and prod builds were originally distinguished via build flavors; Lightbuild instead achieves this by creating multiple app modules (such as a demo app and a prod app), each an empty shell that depends on a different combination of libraries.

Build Variant is the output configuration generated by the Android build system when it combines a build type (such as debug or release) with a product flavor (such as demo or prod). Traditionally, multiple flavors are defined within a single app module via buildFlavors, and Gradle then combines them into multiple variants. Lightbuild does not support this kind of conditional switching within a module; instead, each variant corresponds to a separate empty-shell app module, with differentiation achieved by depending on different combinations of library modules. This design turns "variant selection" from a build-time logical decision into a static declaration in the project structure, which is more consistent with its core philosophy of being declarative and statically analyzable.

Putting It to the Test: Now in Android with 32 Modules

Scott used the Gemini agent to convert the highly modular Now in Android project (about 32 modules) to Lightbuild. The project opened and synced extremely quickly. However, he was also candid about the limitations: Now in Android depends on the Hilt plugin, which Lightbuild does not yet support, and the agent eventually found a workaround. "Not all build configuration features in your current project will be supported—which is why Lightbuild is still in preview."

Outlook and Recommendations

Lightbuild is currently an experimental feature and lacks all the features needed to build and maintain production apps. Google explicitly recommends: continue using AGP and Gradle for production apps, and try Lightbuild in demos and experimental projects. Developers can find getting-started steps on the official documentation page, including installing the Android Studio Canary version and the Lightbuild CLI. Juan and Scott, along with team engineers, will also be at the Agentic AI booth to answer questions and look forward to community feedback to shape the product's evolution.

For teams focused on AI-assisted development workflows, Lightbuild represents a paradigm shift worth watching: turning build configuration from executable code into structured data, which not only makes projects easier for humans to understand but also gives AI agents a reliable interface to operate on.

One-line Summary

Google introduces Lightbuild, an experimental Android build solution that replaces imperative scripts with declarative static data.

Paragraph Summary

Google has released Lightbuild, an experimental Android build experience that aims to replace imperative Gradle scripts with purely declarative YAML configuration. At its core, it turns project configuration into a deterministic static data graph, enabling the IDE to understand a project without executing scripts and achieving near-instant sync; it also locks transitive dependencies by precomputing and checking in resolve.deps files. App modules are designed as empty shells, with code concentrated in library modules to speed up builds, and product variants are realized through multiple app modules. The CLI provides agent-oriented commands such as query and resolve, with JSON output support. Lightbuild still uses Gradle for execution under the hood and does not yet support plugins like Hilt; the official recommendation is to use it only for experimental projects.