Hilt中:app模块可向依赖模块提供依赖，其他模块为何不行？

没错，:app模块确实有特殊性——它是Android Gradle插件定义的应用模块（Application Module），而像:C这类模块一般是库模块（Library Module），两者的依赖可见性规则完全不同，这就是问题的核心原因。

具体差异解析： #

• 应用模块的特殊处理：
  应用模块的设计目标是最终打包成APK，默认不会被作为依赖供其他模块复用。因此Android Gradle插件放宽了它的依赖可见性限制：当其他模块（比如:B）依赖:app时，:app中所有的依赖（哪怕是用implementation声明的）都会被暴露给依赖它的模块，相当于自动把这些依赖的可见性提升到了api级别。这就是为什么:B能直接使用:app里的依赖。

• 库模块的严格封装规则：
  库模块的设计是为了被其他模块依赖，因此遵循Gradle的标准依赖可见性规则：

  • 用implementation声明的依赖是内部封装的，只会被当前模块使用，不会传递给依赖它的模块（比如:B依赖:C时，无法访问:C里用implementation声明的依赖）；
  • 只有用api声明的依赖才会传递可见，依赖该库的模块可以直接使用这些依赖。

正确的做法： #

1. 不要让库模块（比如:B）依赖应用模块（:app），这是典型的反模式——应用模块包含大量仅自身需要的依赖和代码，会导致依赖膨胀，还破坏了模块的职责边界。
2. 如果需要在多个模块间共享依赖或代码，建议抽离出单独的基础库模块（比如:core），让:app、:B、:C都依赖这个基础模块。
3. 如果:C需要向:B暴露特定依赖，把:C中对应依赖的implementation替换成api即可。

内容的提问来源于stack exchange，提问作者Barrufet