Jugg skips Gradle for the second build of an Android project

The baseline is the whole idea

Jugg is described as an open source Android Studio plugin built by the Tencent Music engineering team for fast incremental compilation and instant hot reload, and its architecture is easier to understand if you start with what it keeps rather than what it does. Gradle stays the source of trusted build outputs. From the latest full Gradle build, Jugg establishes a baseline, then for each subsequent change it detects the change and its impact across source, resources, dependencies and class relationships, compiles only what is needed, and deploys through whichever of several strategies the change allows. The Gradle configuration and task execution that dominates a typical day-to-day build is skipped for the parts that did not change. That is why the headline number is about seconds, and why the first build is not fast.

Deploy strategies from hot reload to reinstall

Deployment is not one mechanism but a set of them, chosen per change. The first and fastest is Apply Changes hot reload through JVMTI, which updates modified code and resources directly in the running process with no restart, and falls back gracefully to hot fix, meaning an app restart without reinstallation, when a code swap is not applicable. Beyond that the README lists incremental APK update and reinstallation, along with multiple APKs, multiple devices, Dynamic Feature, a compatibility deployment path and failure recovery. A hot fix is worth understanding on its own: it restarts the process but keeps the app installed, which is much faster than a reinstall and sidesteps the state loss a full reinstall causes. The design assumes that a change may not fit the fastest path, and the fallback is a documented part of the mechanism rather than a failure mode.

What the plugin refuses to touch

Two design constraints define the adoption risk. Jugg requires only an IDE plugin, and it does not modify Gradle scripts or require SDK integration. A Jugg Run Configuration coexists with the native App Run Configuration, so you can select Jugg for the fast path and switch back to the standard Android Studio build flow at any time, and the README states the two run completely independently and do not interfere with each other. For a team that has spent a year keeping its build files clean, that boundary is the feature. It also means Jugg cannot be blamed for a broken Gradle script, because it never touches one, and it also means there is no Gradle-level hook through which Jugg learns about unusual custom tasks, so a project with custom compilers or unusual build logic will lean on the fallback more often.

Installing it and the first run

Installation happens inside Android Studio rather than from a command line. You open Settings or Preferences, go to Plugins, then Marketplace, search for Jugg and click Install, or you download the offline package from the GitHub releases page, which is published as a zip, and install it through Plugins and the gear menu with Install Plugin from Disk. The plugin is also on the JetBrains Marketplace. After installing, you open an Android project and wait for the Jugg Run Configuration to be created automatically, then select it and click Run. The first Run establishes the Gradle baseline, and after that, editing source or resources and running again gives the second-level bypass incremental compilation. So the workflow to expect is a slow first build and fast ones after, and the first build is not optional, it is the setup step.

The compatibility table is the real specification

The README documents what is supported in a table, and it is more informative than the feature list. On the source and resources side: Java, Kotlin, mixed Java and Kotlin, Compose, KMP, Compose Multiplatform, res, assets, the manifest and native .so files. On the Android project side: DataBinding, ViewBinding, supported annotation processors, incremental dependency compilation, incremental builds for release variants, AabResGuard and custom compilers. On deployment: hot reload, hot fix, incremental APKs, multiple APKs, multiple devices, Dynamic Feature, compatibility deployment and failure recovery. On tests: application and library Android Test, a test results UI and Logcat attribution. On automation: a CLI, MCP, Agent Skills, build and deployment, device and runtime queries, UI automation and remote diagnostics. The repository tree backs that up, with directories for the JVMTI agent, incremental resource tooling under aapt2-inclink, deploy compatibility, platform compatibility, custom compilers, a command line directory and a demo Android project.

The agent and CLI surface

One feature goes beyond build speed: Jugg ships a built-in MCP server, a CLI and Agent Skills named jugg-android-dev-loop, with the stated purpose of automating a full edit, compile, deploy and verify loop. The capabilities table spells out what is exposed for automation, including build and deployment, device and runtime queries, UI automation and remote diagnostics. That is a meaningful shift in what an IDE plugin is for, since a plugin that can be driven by an agent needs machine-readable state and a stable command surface, not just a menu item. The trade-off is that an automated loop that compiles and deploys without a human in the middle will happily apply a change that breaks the app, so the verify step in that loop matters more than usual, and the Logcat attribution feature in the test row is what makes that verification readable rather than a scroll of unrelated lines.

Where Jugg is the wrong tool

Three cases. The first is a small project whose Gradle build is already fast, since the baseline build is pure overhead there and the plugin adds a component to your build loop without removing a bottleneck. The second is release engineering: incremental builds for release variants are listed as supported, but a release build is the one place where you want the full, standard, reproducible pipeline rather than a shortcut layered on top of a baseline. The third is any environment where the plugin cannot coexist with the standard flow, such as a team that standardises on Gradle command line invocation in CI. Against the alternative of Gradle's own build cache and configuration cache plus the Android Studio incremental deploy, Jugg's difference in approach is that it maintains its own baseline and its own impact analysis across class relationships and dependencies, which is more aggressive than what Gradle configuration caching does, and correspondingly more machinery to trust. The README claims the design was validated over 800,000 plus production builds at Tencent Music, which is scale evidence from one organisation rather than a guarantee for your codebase. On licensing, the README badge shows MIT, the repository root carries a LICENSE file alongside a THIRD_PARTY_NOTICES.md and a third_party/ directory, and the plugin is published on the JetBrains Marketplace, so a distribution review has to cover the plugin's own terms and whatever it bundles. That is a question for your own process to answer rather than something the repository settles for you.

Editorial conclusion

Jugg is a good fit for a team doing tight edit-compile-deploy loops on a large Android codebase, where a Gradle configuration and task run dominates the wait, and where the team is willing to accept a plugin that maintains its own baseline alongside Gradle rather than replacing it. It is a poor fit for a small project whose Gradle build is already fast, for a release build where the standard flow should run end to end, and for anyone who cannot accept a plugin that intercepts the build loop. Check three things before you roll it out: that the first Run establishing the Gradle baseline behaves as you expect on your project, since everything after it depends on that baseline, that your team's stack is in the supported list, which covers Kotlin, Java, Compose, KMP, DataBinding, ViewBinding, res and assets, the manifest and native .so libraries, and that the fallback path is understood, because a change outside the incremental path silently reverts to a standard Gradle build.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. tencentmusic/jugg on GitHub