在多模块 Android 项目中，若 Module C 需使用 Module B 定义的注解，仅通过 Module A 间接依赖会导致“Unresolved reference”错误；根本原因在于 implementation 依赖不具备传递性，需改用 api 或显式声明依赖。

在多模块 android 项目中，若 module c 需使用 module b 定义的注解，仅通过 module a 间接依赖会导致“unresolved reference”错误；根本原因在于 `implementation` 依赖不具备传递性，需改用 `api` 或显式声明依赖。

在 Android Gradle 项目中，依赖配置方式直接决定了类与注解能否被下游模块访问。implementation 是默认且推荐的依赖作用域，但它会隐藏依赖的 API——即 Module A 使用 implementation(project(":moduleB")) 声明对 Module B 的依赖后，Module B 中的注解（如 @MyAnnotation）不会暴露给 Module C，即使 Module C 依赖了 Module A。这是 Gradle 的依赖封装机制所致，旨在减少编译耦合与缩短构建时间，但在此场景下却成为障碍。

✅ 正确解决方案一：使用 api 依赖（适用于 Module B 为公共注解库）

在 Module A 的 build.gradle（或 build.gradle.kts）中，将对 Module B 的依赖由 implementation 改为 api：

// Module A 的 build.gradle（Groovy）
dependencies {
    api project(':moduleB')  // ✅ 关键：使 moduleB 的 public API 对上游可见
    // 其他依赖...
}

// Module A 的 build.gradle.kts（Kotlin DSL）
dependencies {
    api(project(":moduleB"))  // ✅ 同样生效
}

随后，Module C 只需正常依赖 Module A 即可访问注解：

// Module C 的 build.gradle
dependencies {
    implementation project(':moduleA')  // ✅ 此时 @MyAnnotation 可被 import 并使用
}

⚠️ 注意：api 会增加编译时耦合，仅建议将 稳定、通用、预期被消费者使用的注解模块（如 annotations 子模块） 通过 api 暴露；避免滥用，否则可能引发意外的 API 泄漏。

✅ 正确解决方案二：Module C 显式声明双依赖（更清晰、更可控）

更推荐的做法是：Module C 同时直接依赖 Module A 和 Module B，尤其当 Module B 是纯注解/处理器模块时：

// Module C 的 build.gradle
dependencies {
    implementation project(':moduleA')
    implementation project(':moduleB')  // ✅ 直接提供注解类
    // 若需运行时保留注解（如反射读取），必须用 implementation
    // 若仅为编译期检查（如 @NonNull），annotationProcessor 也可，但不推荐用于自定义注解引用
}

? 补充说明：annotationProcessor 仅用于注解处理器的编译期参与，它不会将注解类本身暴露给源码。因此，annotationProcessor(project(":moduleB")) 无法解决 @MyAnnotation 导入失败的问题——你仍需 implementation 或 api 来引入注解的 class 字节码。

Android Adb Skill

Android 开发调试技能，通过系统 ADB 工具操作 Android 设备。以下场景必须触发此技能：(1) 直接 ADB 操作——安装 APK、查看设备列表、抓取 logcat 日志、查看已安装应用、清除应用数据、截图、重启设备、拉取/推送文件、查看 CPU/内存/电池信息、adb shell 操作；(2)...

下载

✅ 验证与最佳实践

1. 清理并重载：修改 Gradle 配置后，务必执行：

   ./gradlew clean && ./gradlew --refresh-dependencies

   并在 Android Studio 中点击 File → Sync Project with Gradle Files。

2. 检查注解作用域：确保 Module B 中的注解使用了正确的 @Retention：

   @Retention(AnnotationRetention.SOURCE) // 仅编译期 → 不需要 runtime 依赖
   @Target(AnnotationTarget.CLASS, AnnotationTarget.FUNCTION)
   annotation class MyAnnotation

   若需运行时反射（如 clazz.getAnnotation(MyAnnotation::class)），请改用 AnnotationRetention.RUNTIME，并确保 implementation 引入。

3. 模块职责分离建议：

   • Module B 应仅包含 annotations（接口定义）和 processor（处理逻辑），二者可拆分为 moduleB-annotations 与 moduleB-processor；
   • Module C 仅 implementation moduleB-annotations；
   • Module A（或独立的 app 模块）annotationProcessor moduleB-processor。

综上，“Unresolved reference” 并非代码或 IDE 故障，而是 Gradle 依赖作用域的精准体现。通过合理选用 api 或显式 implementation，即可安全、透明地实现跨模块注解复用。