回退与限制
Jugg 的增量编译依赖最近一次可信的 Gradle 构建产物。回退 Gradle 不是增量链路失效，而是重新生成 APK、class、注解器生成源码和其他基线产物，让下一轮增量可以继续运行。
增量必须建立在可信起点上
“只编译变化部分”的前提是有一份可信的基线。基线缺失、修改范围超出增量能力、设备或部署现场不可信时，Jugg 无法证明当前上下文与完整 Gradle 构建一致，会回到 Gradle 重建基线。回退保护的是后续运行结果，不是对增量能力的否定。
识别失信信号，回到 Gradle 重建基线
回退由三类失信信号触发：没有可信基线、当前修改超出增量能力、设备或部署现场不可信。命中任意一类，Jugg 都会回到 Gradle 重建可信起点，而不是带着不确定状态继续增量。
| 场景 | 原因 |
|---|---|
| 首次运行 | 没有可复用的 Gradle 基线产物 |
build.gradle 变化 | 构建配置和依赖需要重新读取 |
| 注解处理器或插桩场景 | 依赖 Gradle 上下文，增量参数难以确认 |
| 一次性修改文件很多 | 增量收益下降，完整构建更稳妥 |
| Manifest 更新 | Manifest 需要写回 APK 并安装 |
| 设备或部署现场不可信 | 继续部署会基于未经校验的设备状态 |
| 用户主动降级 | 用完整构建刷新基线 |
这些场景的共同点是：Jugg 无法把本轮增量上下文证明为可信。回退是重新建立可信起点，不应被误判为异常。具体触发条件和用户操作建议见 Gradle 回退。
仍以 Gradle 为准的范围
Jugg 不是完整的 Gradle pipeline。以下内容仍以 Gradle 构建为准：
- 完整发布构建和正式 APK / AAB 产物。
- 复杂构建脚本、Gradle plugin 和 variant 逻辑。
- 未明确支持的注解处理器、插桩和生成代码。
- 依赖图的复杂变化。
- 需要完整刷新资源表、Manifest、mapping 或 APK 结构的场景。
大工程里的自定义插件、非标准生成代码和复杂 variant 逻辑不属于默认增量承诺。遇到这类工程逻辑时，应先用 Gradle 刷新基线，再判断能否纳入 Jugg 增量路径。
资源增量的限制
Jugg 定制 aapt2 的增量链接后，可以基于 APK 中的 resources.arsc 和资源内容做增量 link。代价是删除的资源 ID 不会立即从资源表中移除，要等下一次 Gradle 构建刷新基线。这个能力只适用于 debug 开发，不能用于生产构建。
设备与版本的限制
设备厂商对 JVMTI / Apply Changes 的支持存在差异。Jugg 会通过自有 JVMTI Agent、兼容部署或经典热修复路径降低设备差异影响，但设备能力仍会影响本轮能否在线替换、是否需要重启，或是否需要重新安装。