didi/booster: a Gradle plugin for Android bytecode and resource optimization

The quality problems Booster targets in Android builds

Booster exists because Android apps accumulate quality debt as they grow: UI thread blocking from careless I/O calls, thread explosion from third-party SDKs, and APK bloat from resources that are referenced but never reached at runtime. The README frames the goal as solving "quality problems with the increase of APP complexity, such as performance, stability, and package size." That is a broad mandate, and the project answers it with a set of narrow, composable modules rather than one switch.

The audience is Android build engineers and platform teams who already control their Gradle configuration. This is not an app-level library you add to dependencies and forget. It plugs into the build, and the README's own advice is to integrate only the modules that address problems you have actually encountered: "figure out the features you really need, then choose the right module for integration." Teams that expect a single flag to fix performance will be disappointed; teams with a specific crash or a specific size regression have a much better fit.

The repository layout reflects that modularity. Top-level entries include booster-transform-toast, booster-transform-thread, booster-transform-r-inline, booster-transform-logcat, booster-transform-media-player, booster-instrument-res-check, and a family of version-specific adapters from booster-android-gradle-v8_0 through booster-android-gradle-v9_0. Each adapter exists because the Android Gradle Plugin's internals change between releases, and Booster has to track them.

How the transform pipeline and version adapters work

The mechanism is bytecode and resource rewriting at build time. Booster registers itself as a Gradle plugin, and once applied it participates in the Android Gradle Plugin's transform stage. The README's own verification step looks for a task named transformClassesWithBoosterForDebug in the build output, which tells you the plugin has inserted itself into the class transformation chain for the debug variant.

From there, individual modules do the work. booster-transform-toast rewrites Toast calls so that a crash caused by Toast on Android API 25 is handled globally instead of at each call site. booster-transform-thread intervenes in thread creation, which matters when third-party SDKs start threads you do not control; the README notes that too many threads can cause OOM. booster-transform-r-inline inlines the R resource index, which is one of the size-reduction paths. booster-instrument-res-check and the instrument modules cover detection rather than rewriting, such as flagging APIs that may block the UI thread.

The version adapter directories are the part that determines whether any of this works on your project. Because AGP internals are unstable across releases, Booster ships a separate compatibility module for each AGP line it supports. The README's table maps AGP versions to minimum Gradle versions and minimum Booster versions: AGP 9.0.x and 8.12 need Booster 5.2.0+, AGP 8.2 through 8.3 need Booster 5.0.0+, and AGP 7.4 drops back to Booster 4.16.3+. That table is the single most important document in the repository for anyone planning an upgrade.

Installing Booster in a Gradle build and confirming it runs

Booster is distributed through Maven Central under the group com.didiglobal.booster, with the plugin artifact named booster-gradle-plugin. The README's buildscript example pins a version through an ext property, which is the pattern the project recommends. Note that the README's example uses 5.1.0 while the compatibility table references 5.2.0+ for the newest AGP lines, so pick the version from the table that matches your AGP rather than copying the snippet verbatim.

buildscript {
    ext.booster_version = '5.1.0'
    repositories {
        google()
        mavenCentral()
    }
    dependencies {
        classpath "com.didiglobal.booster:booster-gradle-plugin:$booster_version"
    }
}

After the classpath entry, the plugin is applied to the application module alongside the Android plugin. The README shows this as a separate apply step rather than a plugins block, which is the older but still supported style.

apply plugin: 'com.android.application'
apply plugin: 'com.didiglobal.booster'

Since Booster 3.0.0 the plugins DSL is also supported, which is cleaner for modern builds. The README gives this form directly.

plugins {
    id 'com.didiglobal.booster' version '5.1.0'
}

To confirm the plugin actually engaged, the README prescribes a dry run. A dry run resolves the task graph without executing it, so it is fast and safe to run before a real build.

./gradlew assembleDebug --dry-run

If transformClassesWithBoosterForDebug appears in the output, the plugin is enabled. If it does not appear, the plugin was not applied, the classpath entry is missing, or the version is incompatible with your AGP. That check is the fastest way to separate a configuration mistake from a transform that simply has nothing to do.

Where Booster stops being the right tool

The hardest constraint is AGP compatibility. The README is explicit: "Due to AGP 8's incompatible changes, AGP 7.x and below are no longer supported, if you are still using AGP 7.x, please use Booster 4.x." If your project is pinned to AGP 7.x for reasons outside your control, you are on a maintenance branch of Booster by definition, and features added in 5.x are unavailable to you.

The 4.x to 5.x migration is a second boundary. Most Task-based modules were removed in Booster 5.0.0. The README states that Transform-based modules still work without breaking changes, but that qualifier only helps if the module you depend on is Transform-based. A team that built custom Task-based modules on top of Booster 4.x has real migration work ahead, and the README points to a separate migration page rather than describing the steps inline.

There is also a scope limitation worth stating plainly. Booster operates on the build output: bytecode and resources. It cannot fix a main-thread I/O call that a developer writes after the transform has run, and it cannot reason about runtime behaviour that only appears under specific device conditions. The performance detection modules flag suspicious API usage; they do not prove a frame drop. Treat detection output as a lead to investigate, not a verdict.

The README's headline claims about stability and package size come from the project's own description, not from an independent measurement, and the README does not state the conditions under which those ranges were obtained. Verify the size effect on your own APK before treating any number as a target.

Booster versus R8 and the Android Gradle Plugin's own shrinkers

The obvious comparison is R8, which ships with the Android Gradle Plugin and performs code shrinking, resource shrinking, and optimization as part of the standard build. The difference in approach is where the work happens and who controls it. R8 is a compiler-stage optimizer with a rule language (keep rules) that you configure through proguard-rules files. Booster is a transform-stage rewriter: it inserts itself into the class transformation chain and applies module-specific bytecode edits, which means it can change call sites in ways a shrinker would not, such as rewriting every Toast invocation to route through a fixed implementation.

That difference cuts both ways. R8 is maintained in lockstep with AGP, so version drift is not your problem. Booster maintains its own adapters for each AGP line, which is why the repository carries booster-android-gradle-v8_0 through booster-android-gradle-v9_0. You get finer control over specific patterns, and you take on the responsibility of tracking AGP releases.

Booster is also not a replacement for a runtime APM tool. It runs at build time and produces a modified artifact; it does not collect crash reports or frame timings from production devices. If your goal is to know what is slow in the field, Booster's detection modules are a static complement to that, not a substitute for it.

Maintenance, licensing and the cost of upgrading

The repository is not archived, and the last push was on 2026-08-09, which is recent enough that the project is being touched. The most recent tagged release listed is v5.1.0 from 2025-04-12, with v5.0.0 before it in 2024-07-21. The gap between the latest release and the latest push means there is commit activity that has not yet been cut into a tagged release, so anyone pinning to a released version is working with code that is at least a few months behind the branch.

Upgrade cost is driven almost entirely by the AGP compatibility matrix. Every AGP major bump forces a Booster version bump, and the README's table shows those bumps are not optional: AGP 8.2 requires Booster 5.0.0 or later, while AGP 9.0.x requires 5.2.0 or later. A team that upgrades AGP without upgrading Booster will find the plugin either fails to apply or silently produces no transform task. Budget for the two upgrades as a single unit of work.

On licensing, Booster is Apache-2.0, and the repository ships LICENSE.txt at the top level. Apache-2.0 is a permissive licence that permits commercial use and modification, and it includes an explicit patent grant. It also requires that you preserve copyright and licence notices for redistributed portions and state significant changes. Because Booster is a build-time tool rather than a library you ship inside your APK, the redistribution question usually does not arise for the compiled output, but it does arise if you fork the plugin or vendor modified modules internally. That is a description of the licence text, not legal advice; have counsel review anything you redistribute.

Editorial conclusion

Adopt Booster if you are on AGP 8.x or 9.0.x and want specific, module-by-module fixes such as global Toast crash handling on Android API 25, thread management for third-party SDKs, or R inline shrinking, rather than a single monolithic optimizer. Do not adopt it if you are pinned to AGP 7.x or below, because the README states those versions are no longer supported in Booster 5.x and you would have to stay on Booster 4.x. Before committing, verify three things against your own build: that your Gradle and AGP versions fall in the compatibility table for the Booster version you pick, that ./gradlew assembleDebug --dry-run lists transformClassesWithBoosterForDebug, and that any Task-based module you relied on in 4.x has a Transform-based replacement, since most Task-based modules were dropped in 5.0.0.

Frequently asked questions

Official sources

1. didi/booster on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases