This interesting article from Jeroen Mols shows a possible way to modularize an Android app. It basically divides the modules in 3 layers (App
, Features
and Libraries
). App
communicates directly with Features
and Features
can depend on Libraries
. This means that App
doesn't interact directly with Libraries
.
Now, if I understood correctly HILT documentation, the module that contains the Application
(which is the App module) and thus it has the HILT entry point (HiltAndroidApp
) needs to know about all other modules that want to use dependency injection. So for example if I have a library called libraries:analytics
, I would need my App module to depend on it, so I would be forced to have in my app/build.gradle
:
implementation project(":libraries:analytics")
which violates the separation and abstraction the whole architecture was trying to achieve.
Is my interpretation correct? If so, what would you do for not breaking the suggested architecture?
If you are using Hilt Gradle Plugin and you have transitive dependencies of other modules you can apply below to your :app/build.gradle and remove the transitive module(s) dependencies from it.
hilt {
enableAggregatingTask = true
}
Also refer for more details: https://github.com/google/dagger/issues/2123#issuecomment-928064317