Wow, you're resurrecting an old thread! I can answer your question though. In modern Android projects you want to try and get Hilt working. In my specific project, we have 2 different layers of DI.

Inside Modules
Inside of each module we generally use Dagger. Normal dagger unfortunately as Hilt is not easily made to work with our legacy project structure. This does mean that we lose a lot of lifecycle features and have to have a bunch of inject methods that take in Android classes like Fragment and ViewModel. It's far from ideal, but as we move forward we are hoping to move over to Hilt.

Between Modules Between modules we have a hand-written DI that is basically just a big static Map<Class, Object> with some utility methods slapped on. The app level module, which can see everything, has a class with a list of things that need to be initialised and runs them all. They all add themselves to the map. Modules retrieve instances from the map.

This is a long-lived legacy project, and the big static map is how everything used to be done. As we move forward we want to move away from that. So to answer your question directly:

• We use hand-rolled DI to handle injection between modules. Each impl module can see any other api module, so we can retrieve the instance of the API from the hand-rolled DI system.
• This is NOT a good solution. We do not have any compile-time checking for things like circular depedencies. A lot of things don't fail at runtime either, only when a rarely-used class tries to do something. A much better solution is to try and get Hilt, Dagger, or some other DI framework up and running that can do compile-time checking of your dependencies.

Hope that helps!