Source compilation

Jugg incrementally compiles Java and Kotlin sources changed in the current run and can continue processing sources or class inputs produced by supported compilation capabilities. Compilation produces deployable DEX or Release re-obfuscation artifacts. Resources, AndroidManifest, .so, and other files are outside this page's scope. For compiler isolation, mixed Java/Kotlin compilation order, and DEX structure alignment, see Incremental source compilation.

Supported scope

User scenario	Current support	User-visible result
Change Java source	Supported	The change enters incremental compilation and subsequent deployment
Change Kotlin source	Supported	The change enters incremental compilation and subsequent deployment
Change mutually dependent Java and Kotlin in the same run	Supported	Both languages compile against the latest declarations from the current run
Kotlin Android Extensions	Supported for legacy project compatibility	Synthetic references in older projects can still participate in incremental compilation
Kotlin Compose source	Supported	Compose-related class/DEX output is produced incrementally; see Kotlin Compose
Sources produced by supported capabilities	Supported as input	Sources generated by DataBinding/ViewBinding, explicitly supported annotation entry points, and similar capabilities can continue compiling
Generated or transformed class artifacts	Supported as input	Continues producing deployable DEX; Release builds proceed to re-obfuscation

Trigger and result

Java / Kotlin or supported generated artifacts change
  -> Compile sources changed directly in this run and generated sources
  -> Add affected sources for further compilation when needed
  -> Produce DEX or Release re-obfuscation artifacts
  -> Hand them to deployment

The common result is that directly changed sources compile first. If interfaces, parent classes, constants, generated sources, or Release inline behavior affect other files, Jugg adds further compilation before deployment. Multiple compilation rounds in the log do not mean the first round failed.

Boundaries

• Incremental source compilation requires the latest trustworthy Gradle build to provide the APK, classpath, compiler arguments, and generated-source baseline. The first run or an invalid baseline uses Gradle first.
• Jugg falls back to Gradle when the change set exceeds current incremental limits or when build configuration, dependencies, or source set context changes.
• When an entire Java/Kotlin source file is deleted or renamed, Jugg does not remove existing classes from the device. Old classes may remain accessible through direct references, reflection, or class loading. Run a full Gradle build only when the old class must truly disappear and the APK and reference baseline must be refreshed.
• Generated sources must first be produced by a supported capability. Do not assume that arbitrary annotation processors, KSP, or KAPT can run completely outside Gradle.
• Release/minified builds depend on a mapping baseline that matches the current APK. If it is missing, inconsistent, or produces abnormal runtime results, run a Gradle Release build to re-establish the baseline.

Related pages

• Resource compilation
• Recompilation
• Release compilation
• Gradle fallback
• Compilation stages
• Incremental source compilation