# The Android Build System Is Broken

DevFeed: [The Android Build System Is Broken](<https://devfeed.tech/articles/the-android-build-system-is-broken-20975.md>)

Original publisher: [Read original article](<https://jakewharton.com/the-android-build-system-is-broken/>)

Published: 2012-07-22T00:00:00Z

Content type: opinion

Language: en

Sources: [Jake Wharton](<https://devfeed.tech/sources/jake-wharton.md>)

Topics: [Android](<https://devfeed.tech/topics/android.md>), [Dependency management](<https://devfeed.tech/topics/dependency-management.md>), [Development](<https://devfeed.tech/topics/development.md>), [make](<https://devfeed.tech/topics/make.md>), [Maven](<https://devfeed.tech/topics/maven.md>), [Gradle](<https://devfeed.tech/topics/gradle.md>), [IntelliJ IDEA](<https://devfeed.tech/topics/intellij-idea.md>), [Java](<https://devfeed.tech/topics/java.md>), [Tooling](<https://devfeed.tech/topics/tooling.md>), [Command-line interface](<https://devfeed.tech/topics/cli.md>), [XML](<https://devfeed.tech/topics/xml.md>)

Tags: [android](<https://devfeed.tech/tags/android.md>), [build](<https://devfeed.tech/tags/build.md>), [build-system](<https://devfeed.tech/tags/build-system.md>), [configuration](<https://devfeed.tech/tags/configuration.md>), [dependencies](<https://devfeed.tech/tags/dependencies.md>), [development](<https://devfeed.tech/tags/development.md>), [gradle](<https://devfeed.tech/tags/gradle.md>), [ide](<https://devfeed.tech/tags/ide.md>), [integration](<https://devfeed.tech/tags/integration.md>), [intellij](<https://devfeed.tech/tags/intellij.md>), [intellij-idea](<https://devfeed.tech/tags/intellij-idea.md>), [java](<https://devfeed.tech/tags/java.md>), [library](<https://devfeed.tech/tags/library.md>), [make](<https://devfeed.tech/tags/make.md>), [tooling](<https://devfeed.tech/tags/tooling.md>)

## AI overview

The article argues that Android's build tooling fails as projects become more complex, especially with multiple modules, library dependencies, and overlapping JAR dependencies. It criticizes the combination of scripting, XML configuration, and loosely integrated IDE settings, and calls for robust dependency management, build ordering, support for pure Java modules, and seamless IDE integration.

## Source excerpt

The blessed souls in the Android world with regard to compilation are Eclipse and ant. Both serve admirably if you have a small-to-medium-sized app. You might even pull in a library project and a jar or two. This works great. As the complexity grows beyond this, however, both of these players break down and you are left to fend for yourself. Advanced configurations which are designed to make it more efficient for you, the developer, end up causing unnecessary strain because the build system cannot handle it. When you have multiple modules for production and development versions of your app so that both can be installed at once and library projects that depend on library projects that depend on library projects--all of which have different overlapping jar dependencies--you are on your own. Why is this? Well it is mostly because I have been lying to you. Android does not have a build system. What Android has is a scripting language that has been shoved unceremoniously into XML, a default configuration that attempts to cover all of your use cases, and an IDE whose configuration attempts to mirror the scripting language configuration but has only marginal integration. This is awful. The Android community should settle for nothing short of the following: Dependency management - You should never have to copy a jar or library project into your tree. Version number differences should automatically be resolved. Transitive dependencies should be recursively pulled in. Build order - Multi-module builds are a directed, acyclic graph and the order of their compilation can be determined by the build system. If you add a dependency between two modules the order should automatically change to accommodate. Non-Android projects - Modules should not have to be Android library projects to be part of the build path. Pure Java projects (and anything that compiles to class files) must be supported. Seamless IDE integration - Changes to configurations should be reflected in both command-line