Сергей

что бросается в глаза
"https://faucetpay.io/api/v1/" сделать "https://faucetpay.io/api/v1"

Если планируете заняться профессионально , то нужно знать два языка. Если пишите для себя достаточно kotlin.
Сейчас почти все проекты начинаются как kotlin. И большинство переписываются (или дополняются) на котлин. Т.е. вероятность, что на легаси проектах будет java есть.

Советы на то, что я понял из вопроса)
1. разделить callback'и и rx. Т.е сделать обвертки которые возвращают Observable/Single/... т.е. типа (назовем) RxB
2. на более абстрактном уровне работа с RxB . стандартные merge, flatMap и тд (стандартный код Rx)

и) Лучше вместо PublishSubject использовать PublishRelay

пункты стандартные. Можно почитать почти во всех книгах. Главное разделить на уровни и тогда все станет ясно
1) callback -> rxjava
2) rxjava код
3) rxjava подписка в ui

создать расширение
DatePickerDialog.updateDate(Calendar)...
далее

val datePicker = DatePickerDialog(this).apply{
    updateDate(Calendar.getInstance())
    setOnDateSetListener{_,.....
            textView2.text = ....
    }
}

datePicker.show()

Cуть в том, что код в активити сложно тестируем. Кроме того, проблема разрастания активити, включение в него разного рода кода который работает с вьюхами, логикой, базой данных, сервисами и проч и проч.
Поэтому программистами искались выходы и находились. )
MVP был придуман задолго до андроида. Суть его (как и других аналогичных шаблонов) в разделении модели и ui. Особенность в том, что мы делаем полностью пассивную вьюху, логику вьюхи переносим в presenter.
схематично это так: есть интерфейс view. активити реализует этот интерфейс. презентер знает об этом интерфейсе.
Получается презентер не зависит напрямую от активити, только от некого интерфейса. Поэтому его сравнительно легко тестировать (подставляя свою заглушку view)
Так решается две основных проблемы:
- код стал более тестируемым
- код разделен на пассивную активити и ее логику в презентере.
По вопросам:
1. активити читает пароль и логи и передает их в презентер (вызывая соотвествующие методы презентера). а он далее из обрабатывает.
2. отрисовку данных делает активити с интерфейсом (названным например ActivityView). презентер имеет ссылку на этот интерфейс (активити передает свою ссылку ему), а далее вызывает например activityView.setText(text)
3. есть два подхода
а) время жизни презентера равен (не больше) времени жизни активити
б) время жизни презентера больше времени жизни активити
соотвественно а) данные сохраняются в budle и передаются в презентер
б) данные хранятся в презентере
4 - выше
5. активити - пассивный объект. управление через презентер. любая хоть немного сложная логика в презентер.
Применение интерфейсов обязательно. иначе потеряем тестируемость и не избавимся от жесткой зависимости презентер-активити.

это все описано очень неточно. например вместо "активити" можно подставить "фрагмент". но суть надеюсь понятна.

время нужно засекать по часам. хендлер нужен только для обновления view.

1) в layer-list сделаете кнопку с иконкой и нажатую кнопку
в selector сделаете кнопку с двумя состояниями (или больше) (первое с press=true)
сделаете background = вашему selector
2) сделать две иконки круглые - одна нажата вторая нет. сделать на них селектор и вставить его в бекграунд кнопки
3) сделать CardView. сделать ее нажимаемой и скруглить углы до окружности.

dp везде одинаков. Кнопка будет везде одного размера. Другое дело, что экраны могут быть маленькие и большие. Поэтому относительный размер кнопки по сравнению с экраном может быть разный. Если это тебе не нравится, то делай относительные размеры кнопок.

полезно

это интересно и полезно
определяем модель которая будет возвращать картинку (ресурс) и текст (ресурс)
пример в разделе Defining a Model. далее по шаблону.

никак нормально)
некоторые вещи специально делаются, что бы вызываться на маин потоке.
если очень есть желание, то сделайте обвертку и назовите по другому.
возможно также, что процедурке (методу), нужен не ui- поток, а просто Looper. Тогда добавьте лупер.
Из вопроса не понятно, что нужно.

Public files: Files that should be freely available to other apps and to the user. When the user uninstalls your app, these files should remain available to the user. For example, photos captured by your app or other downloaded files should be saved as public files.

Save files on device

как то все запутано.

savedInstanceState Bundle: If the activity is being re-initialized after previously being shut down then this Bundle contains the data it most recently supplied in onSaveInstanceState(Bundle). Note: Otherwise it is null.

при пересоздании не будет нул.
Для Вашего случая, может отделить логику от презентации?
Например количество попыток это скорее понятие существующее на уровне всей игры, а не на уровне (и времени жизни) активити. Поэтому и привязывать его к жизни приложения (Application).
Думаю проще будет, чем гонять данные из первой активити в третью