Your Domain Module should define interfaces for all the repositories it needs. What you are calling your Repository Module should have public classes that implement the repository interfaces. Doing this keeps your domain classes free of any outside references. Any data the domain classes need will come from objects implementing the repository interfaces defined in the Domain Module.
The Repository Module certainly depends on the domain classes, but since the repositories implement interfaces defined in your Domain Module no direct references to the concrete repository classes should exist in your Domain Module.
If I define the injection in the data module, then I'm coupling presentation module to the data module, also making the repository interface useless.
Neither the Domain Module nor the Repository Module should have any knowledge about a dependency injection container. DI containers should be configured near the composition root of your application, e.g. the
main method or some sort of "application" class. Any dependencies that should be passed to any of the domain or repository classes should be done so through constructor injection, thus eliminating references to DI classes in the domain and repository modules.
Create a data module with the repositories and DataSources that depends on the apimodule (and eventually databasemodule) and the domain module.
This seems a little over complicated to me. Creating a Repository Module makes sense, but then further splitting it into a Data Module, API Module and Database Module simply because the storage technology is different seems like unnecessary separation. There is nothing wrong with your Repository Module having knowledge about web APIs and database queries. This module's primary purpose is data storage and retrieval. Keep It Simple.
Move the activities and viewmodels to presentation module that only depends on the domain module.
Here again this might be unnecessary separation. Once you get to activities and view models code becomes application specific. Unless you need to reuse activities and view models in multiple applications keep them in the same module: the Application Module, if you will. Only when you see a need to reuse this code should you spin it off into its own module. YAGNI is your best friend here.
Creating a Presentation Module seems like overkill. So does creating API and Database Modules, and YAGNI again gives us some guidance. That being said, creating domain and repository modules makes perfect sense because it allows these to be decoupled, and facilitates testing.