在 Android 多模块项目中，若模块 C 需使用模块 B 定义的注解，但仅通过模块 A 间接依赖模块 B，会导致“Unresolved reference”错误；根本原因在于 implementation 依赖不具备传递性，需改用 api 或显式声明注解依赖。
在 android 多模块项目中，若模块 c 需使用模块 b 定义的注解，但仅通过模块 a 间接依赖模块 b，会导致“unresolved reference”错误；根本原因在于 `implementation` 依赖不具备传递性，需改用 `api` 或显式声明注解依赖。
在 Android Gradle 构建系统中，依赖传递性由配置关键字严格控制：implementation 仅对当前模块可见，不会暴露给上游依赖者；而 api（来自 Gradle 的 Java Library Plugin）则会将依赖的 API 向上透出，使模块 C 能访问模块 B 中声明的注解类。
正确配置方式一：启用 API 传递性（适用于模块间强耦合场景）
在模块 A 的 build.gradle（或 build.gradle.kts）中，将对模块 B 的依赖由 implementation 改为 api：
// Module A's build.gradle
dependencies {
api(project(":moduleB")) // ✅ 使 moduleB 的 public 类（含注解）对 moduleC 可见
}模块 C 仍以 implementation 引入模块 A 即可：
// Module C's build.gradle
dependencies {
implementation(project(":moduleA")) // ✅ 此时 MyAnnotation 等注解可被 import 并使用
}⚠️ 注意：此方式会使模块 A 的 API 表面膨胀，若模块 B 仅提供注解（无运行时逻辑），可能引入不必要的编译期耦合，不推荐作为默认方案。
Android 开发调试技能，通过系统 ADB 工具操作 Android 设备。以下场景必须触发此技能：(1) 直接 ADB 操作——安装 APK、查看设备列表、抓取 logcat 日志、查看已安装应用、清除应用数据、截图、重启设备、拉取/推送文件、查看 CPU/内存/电池信息、adb shell 操作；(2)...
正确配置方式二：模块 C 显式声明注解依赖（推荐做法）
更清晰、更符合职责分离原则的做法是：模块 C 直接声明对注解模块（moduleB）的 implementation 依赖，并在需要时添加 annotationProcessor（如需在模块 C 中触发注解处理）：
// Module C's build.gradle
dependencies {
implementation(project(":moduleA"))
implementation(project(":moduleB")) // ✅ 注解类编译期可用
annotationProcessor(project(":moduleB")) // ✅ 若模块 C 内部也需运行注解处理器
}✅ 优势：
- 依赖关系明确，避免隐式传递带来的维护风险；
- 模块 C 对注解的使用不依赖模块 A 的内部实现细节；
- 兼容 Kotlin Multiplatform、KAPT 和 Java Annotation Processing 等多种场景。
额外验证建议：
- 确保模块 B 的
build.gradle中已正确发布注解类（即注解应声明为@Retention(RetentionPolicy.CLASS)或SOURCE，且未被androidTest或testImplementation作用域限制）； - 清理并重建项目：
./gradlew clean && ./gradlew build，避免缓存导致的 IDE 误报； - 在 Android Studio 中执行 File → Invalidate Caches and Restart → Invalidate and Restart，确保索引刷新。
综上，解决 “Unresolved reference” 的核心在于理解 Gradle 依赖配置的语义差异——不要依赖 implementation 的隐式传递，而应主动声明所需注解模块，这是构建健壮、可维护多模块 Android 工程的关键实践。
