Annotation processors
Jugg provides built-in incremental handling only for a small set of explicitly listed annotation entry points and includes their generated sources in the current source compilation. When existing Hilt generated artifacts are available, Jugg can also restore the Hilt bytecode shape of Android entry-point classes before DEX generation. Other APT, KAPT, or KSP processors are handled by Gradle by default; a project can connect a dedicated adapter through a custom compiler.
Supported scope
| Annotation / entry point | Supported | Implementation |
|---|---|---|
Add a com.tencent.kuikly.core.annotations.Page / @Page page | Yes | Adds missing registrations to the existing route entry point and includes the updated entry point in the current source compilation |
Delete, rename, or change an existing Kuikly @Page route | No | Does not remove old route registrations; Gradle must regenerate the complete entry point |
ARouter @Route / @Autowired / @Interceptor | Yes | Runs the project's processor when current relevant inputs differ from business classes, supports project APT/KAPT and KSP1/KSP2, and compiles generated Java/Kotlin; detection failures warn and skip generation, while actual generation failures or disappearing generated classes stop the task |
Use KSP1 com.squareup.moshi.JsonClass / @JsonClass | Yes | Uses the project's KSP1 compiler plugin to generate the Moshi adapter, then continues source compilation |
Use KSP2 com.squareup.moshi.JsonClass / @JsonClass | No | Does not run a KSP2 processor independently and can only continue compiling sources already generated by Gradle |
DataBinding <layout> | Yes | Uses the dedicated DataBinding annotation processor to generate mapper, BR, and binding-related sources |
Change ordinary logic in an existing @AndroidEntryPoint / @HiltAndroidApp entry point with Hilt 2.41 through 2.60.1 | Entry-point transformation supported | Reuses Hilt_* and related artifacts from the latest Gradle/Hilt build, restoring the parent class, super calls, and Receiver injection entry before DEX generation |
| Change Hilt injected fields, bindings, constructor dependencies, or entry-point annotations | Regeneration not supported | Does not run Hilt/Dagger processors; run a Gradle build to refresh generated code and the component graph |
NOTE
Jugg does not run annotation processors outside the explicitly listed entry points by default. A project can provide an adapter through a custom compiler. Without an adapter, use the corresponding Gradle build when those sources must be regenerated.
Boundaries
- Incremental Kuikly
@Pagehandling depends on the latest route-entry baseline generated by Gradle/KSP and only adds missing registrations. Use Gradle to remove stale registrations after deleting a page, changing a route, or renaming a page class. - ARouter requires project processor dependencies: APT/KAPT uses
AROUTER_MODULE_NAMEormoduleName, while KSP uses the project's actualAROUTER_MODULE_NAMEorMODULE_NAMEargument. A loaded custom processor instance with the same ID takes over; the adapter must be recompiled against the current Jugg interface. For Fragment selection, migration, and known boundaries, see Custom compilers. - Ordinary ARouter method-body changes and equivalent constant or default-value expressions do not regenerate. All relevant annotation inputs are compared against current business classes. If association or resolution fails, old indexes may remain stale for this module round while normal source compilation continues; if classes are then updated, the next round is not guaranteed to regenerate; generated-class shrinkage still requires a complete Gradle build. See Custom compilers for specific boundaries.
- Moshi KSP is triggered only when the current Kotlin source explicitly uses
com.squareup.moshi.JsonClassand the project contains the corresponding KSP dependency. - ARouter KSP1/KSP2 regenerates with the current variant's project processor, engine, and arguments, consuming only successful outputs from the current round. Moshi KSP2 still only compiles sources already generated by Gradle.
- Hilt entry-point transformation has been checked against the official transformation semantics from Hilt
2.41through2.60.1. It supports the Receiver field marker used by2.41through2.48.1and the annotation marker used starting with2.49. It handles only Android entry-point classes backed by existing generated artifacts and does not mean that Jugg can run Hilt/Dagger annotation processors independently. Ordinary method-body changes can take effect incrementally; any change that requires updated generated code or a component graph must first use a complete Gradle build. - If the matching
Hilt_*generated parent is missing or unreadable, the current compilation fails with an explicit request to run a complete Gradle build. Jugg does not continue to DEX generation with the untransformed class. - After changing processor dependencies, compiler plugins, arguments, or generation rules, complete Sync if the project model changed, then run a Gradle build to refresh the generated-source baseline.