@HiltAndroidApp注解类在Framework模块而非App模块的问题排查

• 编译时组件归属错误
  Hilt要求@HiltAndroidApp注解的Application类必须放在应用的主模块（通常是App模块），因为它是Hilt根组件的生成入口。如果放在Framework模块，编译时会直接抛出错误，提示根Application不能在非主模块声明——毕竟Android系统的应用入口是绑定到App模块的Manifest，Hilt的代码生成逻辑会和这个绑定关系冲突。

• Manifest配置与Hilt逻辑不兼容
  就算你在App模块的AndroidManifest.xml里声明Framework模块的Application类，Hilt在运行时初始化组件时，会因为根组件代码生成在Framework模块，无法和App模块的应用上下文正确绑定，导致Service里的依赖注入直接失败，比如@Inject标记的变量始终为null。

• 模块依赖方向矛盾
  常规结构是App模块依赖Framework模块，而Hilt的组件初始化需要从根Application向下传递依赖上下文。如果根Application在Framework模块，后续要是App模块的Service需要依赖Framework模块之外的类，会出现依赖反转的问题——Framework模块不能反向依赖App模块，Hilt无法生成正确的组件桥接代码。

• 单例作用域失效
  Hilt的@Singleton作用域是绑定到@HiltAndroidApp对应的根组件上的。如果根组件在Framework模块，App模块的Service想要获取单例依赖时，会因为跨模块的组件作用域不匹配，导致无法拿到正确的单例实例，甚至抛出依赖找不到的异常。

• 维护和调试成本增加
  这种不符合Hilt常规用法的结构，会让后续排查依赖注入问题变得困难，其他开发者接手时也容易因为不熟悉这种非常规配置踩坑，增加团队的协作成本。

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