# Using an Anti-Corruption Layer to Stabilize Android Gradle Plugin Builds

DevFeed: [Using an Anti-Corruption Layer to Stabilize Android Gradle Plugin Builds](<https://devfeed.tech/articles/nihilism-and-the-anti-corruption-layer-30464.md>)

Original publisher: [Read original article](<https://dev.to/autonomousapps/nihilism-and-the-anti-corruption-layer-560n>)

Author: Tony Robalik

Published: 2022-06-24T21:29:36Z

Content type: article

Language: en

Sources: [DEV Community: Tony Robalik](<https://devfeed.tech/sources/dev-community-tony-robalik.md>)

Topics: [Android Gradle Plugin](<https://devfeed.tech/topics/android-gradle-plugin.md>), [migration](<https://devfeed.tech/topics/migration.md>), [modules](<https://devfeed.tech/topics/modules.md>), [Android](<https://devfeed.tech/topics/android.md>), [Google](<https://devfeed.tech/topics/google.md>)

Tags: [android](<https://devfeed.tech/tags/android.md>), [android-gradle-plugin](<https://devfeed.tech/tags/android-gradle-plugin.md>), [api](<https://devfeed.tech/tags/api.md>), [architecture](<https://devfeed.tech/tags/architecture.md>), [coding](<https://devfeed.tech/tags/coding.md>), [community](<https://devfeed.tech/tags/community.md>), [development](<https://devfeed.tech/tags/development.md>), [engineering](<https://devfeed.tech/tags/engineering.md>), [gradle](<https://devfeed.tech/tags/gradle.md>), [gradle-plugin](<https://devfeed.tech/tags/gradle-plugin.md>), [inclusive](<https://devfeed.tech/tags/inclusive.md>), [migration](<https://devfeed.tech/tags/migration.md>), [modules](<https://devfeed.tech/tags/modules.md>), [software](<https://devfeed.tech/tags/software.md>)

## AI overview

This article discusses an anti-corruption layer built to shield a large Android repository's build from breaking changes in the Android Gradle Plugin. It explains how the approach supports build stability and migration to newer releases, while warning that its cost and complexity suit only sufficiently large projects.

## Source excerpt

Every now and then someone asks me if I intend a more technical follow-up to Herding Elephants, which was a fairly high-level overview of the strategy I initiated to modernize that large Android repo I help maintain. And the answer is--not really. It is hard to appreciate how many moving parts exist in a repo at that scale without seeing it for yourself. Many of the lessons learned are irrelevant for smaller projects, which is most of them. The solutions to these medium-large problems1 are expensive to build and expensive to maintain, and the cost-benefit analysis is only in their favor at a certain, well, scale. Dozens of developers and hundreds or thousands of modules. Millions of lines of code. Of all the components that form part of our current build system, however, one stands out as particularly cool and also as a metaphor for the human condition, which is what I really want to talk about. What to expect if you keep reading I will elaborate on the anti-corruption layer I built to protect our build from upstream changes coming from the rapidly-evolving Android Gradle Plugin, and discuss how this has helped our build maintain stability and migrate to newer releases reliably and with increasing rapidity. I will wave my hands at some of the guard rails I built. I will discourage you from attempting this yourself. I will then pivot to how this relates to nihilism and the human condition. The anti-corruption layer As any Android developer with more than a year or two of experience knows, the Android Gradle Plugin (AGP) is constantly evolving. For the very simplest projects, these changes are largely transparent, but I would guess that most Android projects have had frustrations with these changes over the years. One of the pain points of AGP is that its API is constantly changing. (Google even has a documented "migration timeline" for this API; it spans years.) Google also takes the idiosyncratic perspective that many of its public classes aren't really public API, b