так а "эти модули" вы где создаете вместе с вашими компонентами?

Каждый модуль + его компонент - в своем Gradle-модули

чет все равно как-то мудрено
https://habr.com/ru/post/279641/
вот это например читали? раздел Component dependencies

Судя по этой статье, я все воспринял с ног на голову: Application-scope-компоненты пытался в core-модуле, обьявить, а все, что к конкретным экранам - в AppComponent...

Только все равно не могу раздуплить, как это все повязать (отношения модулей Gradle\отношения компонентов Dagger2)

Получается, что для той же пресловутой видимости, мне надо в или в app-модуль переносить зависимости, или в core

Либо инициализацию оставить в Application, а сами di-классы вынести в core, чтобы их все видели...

тогда им не будет видна часть зависимостей из app-модуля. *stupidface*

Иными словами, если у меня есть класс в модуле core, которому нужен инжект контекста, который инициализируется с AppComponent в Application-классе в модуле app
(в build.gradle app-модуля есть   implementation project(path: ':core')

Соответственно, core-модуль ничего не знает о DaggerAppComponent.
Для того, чтобы это решить я могу:
1) Вынести проблемный класс из core в app модуль, тогда придется все подобные классы переносить в app, где им не место так то.
2) Переместить AppComponent в core модуль (что невозможно, ибо AppComponent также отдает зависимости компонентам из app модуля.

Вопрос именно в видимости одним модулем gradle классов другого модуля.

Мне это виделось так, когда затеял эту заварушку:
Core-модуль: общая модель + db (потом отделю, это на первое время)
Network-модуль: общее API + модель
repository - модуль: работает с получением данных из сети и бд, используя core и network модули.
App - модуль : все экраны приложения + логика

Вот похожий вопрос, где человек вообще отказался от Dagger в таком случае - вначале пробрасывает контекст, а потом уже дергает даггер
https://qna.habr.com/q/703557

Я, например,  в таком случае с контекстом, делал самый нижний android модуль, в который предоставляет контекст и другие андроид штуки.

У этого модуля в компоненте, чтобы его собрать, нужны все эти андроид классы.

Их я передаю из app модуля, т.к. app знает об android модуле и может его создать.

А уже все остальные модули, где нужен контект, просто подключают android модуль и юзают контекст.

Я сейчас (ввиду того, что время поджимает) накостылил какую то мешанину - часть network классов улетела в app модуль, так нет проблем с видимостью классов.

Просто с точки зрения Android все вроде как прозрачно:
Core-модуль: тут модель основная приложения, БД + модель(потом уйдет в отдельный модуль) и всякие утилсы вспомогательные и прочее прочее, что можно подключить в каждый вышестоящий модуль.
Network-модуль - тут сетевая модель + инициализация retrofit-сервисов и их описание.
Repository модуль - дергает core и Network по собственному усмотрению для предоставления необходимых данных
App модуль - беседует через ViewModel с Repository, подписываясь на данные, которые нужно отобразить в UI.

Даггер же, в свою очередь, ломает этот концепт напрочь, ибо инициализация оного происходит в App модуле, о котором не знают нижестоящие модули.
Я наверное, заколебал весь этот чат, и да, я не обладаю повальным опытом и знаниями в архитектуре приложении, равно как и опытом использования Dagger в мультимодульном проекте. Но мне крайне непонятно, как грамотно произвести инициализацию компонентов, чтобы не мешать теплое с мягким.

Мы у себя для каждого модуля делаем синглтон-инжектор и в application модуле просто поочерёдно инициализируем все инжекторы дочерних модулей.
Возможно не аккуратно, но работает.

Сейчас так и сделал. Просто вот типичный пример прямо из текущего проекта:
в модуле common-network есть абстрактный класс AbstractApiClient, которому нужен Context и wrapper для SharedPreferences.

По логике, когда все было в одном модуле - я так и делал: в конструкторе AbstractApiClient говорил:
DaggerAppComponent.builder().application(MyApp.get()).build().inject(this); и был таков. Все работало.

Теперь же, класс MyApp лежит в app модуле, и common-network ничего о нем не знает, как в таком случае правильно заинжектить зависимость? Или это мой косяк архитектуры?

Вместо MyApp.get() доставайте контекст из поля инжектора. А в поле его кладите при инициализации App модуля

Прошу прощения, можно хотя бы простенький пример в вакууме, пожалуйста. Это что-то вроде
 @Binds
   @AppContext
   abstract fun application(app: YourApp): Context
?

Я сейчас от безысходности все компоненты утащил в app-модуль, чтобы проблем не было с видимостью классов. и инициализирую все через костыли различного типа

Только будет не Your App, а context. Модуль же не знает ничего об application.

А сам компонент для common-network можно в этом же модуле объявить, да?

Зависеть надо от интерфейсов и базовых классов, а не конкретных реализаций. Тогда проблем не будет

Да, нужно