Tsudzukeru

Очень зависит от класса-предка, и всей объектной модели языка программирования. Вдруг все классы где-то регистрируются и вызов super - просто данность?

Если он делает в конструкторе работу которую нужно сделать чтобы Вы могли работать с ним, то вызов нужен.
Например класс-предок инициализирует какие-то сокеты или ещё что, а вы решили просто своё свойство дописать,
без super класс работать не будет как надо.
При том вы сами решаете когда это делать, хоть не делать, хоть в начале, хоть в конце, хоть по условию.

Например в callback методах системы Android эти вызовы должны присутствовать. Почему не знаю.

Потому что система видит что вами определен свой код, и делегирует ему вызов системного кода. Если вы замещаете системный код (скрытый в super'ах) - не делаете вызов super (что вообще редко, ибо он завернут в исключительную конструкцию чтоб не сломать UI и дать работать хотяб системному коду, в случае ошибок в вашей программе), если не замещаете а дополняете, делаете.

Чтобы это работало, в компоненте зависимостей должны быть явные provision-методы(геттеры) для всего, что должно попасть в граф другого компонента. В твоём случае надо добавить в AppComponent метод

@Named("app string")
 fun appString(): String

Я не увидел, где у тебя объявлено, что сгенерированный компонент фрагмента будет сабкомпонентом для компонента активити. Если это не так(а это не так), то эта твоя стринга находится в другой части графа, и, конечно, получить к ней доступ не получится.
Я думаю, что в ActivityProvider в ContributesAndroidInjector(modules) ты должен также указывать FragmentProvider. Тогда код нагенерится правильно.

А, соответственно, в AppComponent должны остаться только AndroidInjectionModule, AppModule, и ActivityProvider.

Вот это можно почитать https://m.habr.com/ru/post/336462/

Если это весь код BaseApplication, то конечно же ничего не заинжектится. Магии не бывает, чтобы @Inject поля получили значение, кто-то должен вызвать inject-метод для объекта. У тебя никто этого не делает. Ты должен в AppComponent добавить метод inject (BaseApplication), и вызывать его в onCreate application.

Потому что после загрузки изображения сохраняются в кэше

ctrl + space

Вообще - да, нужно всё внедрять. Давай приведу пример. Вот у тебя какой-то медиа превью конвертер. Не знаю, чем он занимается, но предположим, он форматирует некое превью, фото или видео, так? В этом случае может понадобиться использовать контекст для получения размеров экрана, тк превью на разных экранах может иметь разные размеры. Вот тут-то di и поможет.

Советую почитать книжку Боба Мартина "Чистая Архитектура".

Есть курс на FoxMinded Enterprise Patterns - https://foxminded.com.ua/enterprise-patterns-advan...
Не знаю насколько хорошим этот курс является, но думаю, что это может вам чем-то помочь

Всё происходит правильно. AsyncMethod(param1,param2,ApiKeyStore.CurrentKey) вызывается только один раз, и при каждом retry происходит переподписка к его результату. Поэтому ключ не меняется. Нужно сделать так, чтобы при retry вызывался сам метод, а значит - использовать Observable.defer:

Observable.defer { AsyncMethod(param1,param2,ApiKeyStore.CurrentKey) } 
.doOnError{
    ApiKeyStore.getNextApiKey()
}
.retry(ApiKeyStore.attemptsNumber)

Теперь при retry переподписка будет к defer, и каждый раз будет вызываться AsyncMethod с новыми параметрами.
Как-то так.

Нет, всё очень плохо, так Rx использовать нельзя.
Внутри цепочки сайдэффекты нужно минимизировать, они у тебя на любой чих.
Внутри цепочки не должно быть никаких "освобождений ресурсов" в виде disposables.dispose(). dispose должен быть только вне цепочки. Тем более, что неизвестно, что ты напихал ещё в этот disposable. Зафейлилась одна цепочка - и всё, работа встала полностью, потому что больше ничего ты в этот disposables запихать не сможешь. clear() надо вызывать в случае, когда тебе нужно очистить CompositeDisposable.
.flatMap{ Observable.fromIterable(it)} это вообще что за дичь бессмысленная? просто удали эту строку и ничего не изменится.
Обычно методы типа getVideos что-то возвращают. В твоем случае это должен быть по ситуации Observable/Single.

.onErrorReturnItem(mutableListOf(Video("ErrorId")))

Дичь. Мутабельные данные в стриме - путь в никуда. Только иммутабельные. ErrorId? Orly? Сделай ты sealed класс, в конце концов.
Почитай про SOLID, этот твой метод делает слишком много всего.

Скажите, насколько необходимо запускать эмуляторы со всеми версиями Android в реальной промышленной разработке?

Android Studio подсказывает, если используешь метод, который поддерживается с версией выше, чем текущая минимальная. Поэтому почти всегда заменяю такие методы, чтобы не тестировать на разных смартах.
Эмуляторы полезны для подгона UI к разным размерам устройств. Например, сейчас делаю Custom View, размеры отступов у внутренних блоков зависят от общего количества dp на смарте. На стандартных HD, Hd+, Full HD все корректно обрабатывает, а на кастомных размерах - нет. Спасибо создателям смартов xD

эмуляторы очень сильно тормозят начиная с Android 6.0.

Это норма. Слабый проц, мало оперативки выделено под эмулятор. У меня летает на i5-9600k + 16gb ddr4 2600 МГц.

боюсь, что ноут пыхнет.

Ну, пыхнуть - не пыхнет, но при хорошей нагрузке может синий экран появится, если охлаждение не справится.
Засеки временя на крафт релизных билдов с оптимизацией кода. У меня ~2 минуты с 5 проходами.

Если нужны несколько эмуляторов, в Firebase можно бесплатно прогонять до 10 виртуальных устройств и 5 физических, с разными версиями оси и размерами экрана.