Юзаю mvp, где правильнее всего разместить логику проверки перпишенов ?

Ситуативно. Но вообще, нигде кроме UI это нормально не завязать.

есть экстрималы, которые делают несколько сущностей, чтобы из UI пробросить запрос в Presenter и обратно в обход интерфейса View

конечно в презентере с использованием rxpermissions!

не стоит на view ничего вешать кроме рендеринга

Я тут попробовал app update manager использовать не в ui. Почти нереально, очень тесно завязано на активити или фрагмент(

Кто как менеджит жц кастомных di скоупов? К примеру для флоу/визарда на несколько экранов. Пока что встречал только ручной вариант, где нужно самому обнулять(set null) скоуп в каждом "брейк сценарии" т.е. там где юзер окончательно покидает флоу. Выглядит достаточно рутинно и "способствует багам".

Подумываю над каким-нибудь countRef механизмом, но из-за особенностей андроида пазл пока не складывается. Не понятно как добиться того, чтобы в некоторых кейсах новый экран/скоуп биндил зависимости(увеличивал countRef) раньше, чем предыдущий декрементил их.

Архитектура на фрагментах,  обычно транзакции предсказуемы(достаточно понимать add, replace, addToBackStack), но иногда они могут  менять поведение/оптимизироваться (setReorderingAllowed). Согласно докам - если было закомиченно(pendingTransactions) несколько действий(переходов), то некоторые шаги могут вообще опускаться (пропуская вызовы колбеков жц опущенных фрагментов)

храни компоненты в retained фрагментах в менеджере флоу фрагмента

надеюсь, это шутка 🙈

имеешь в виду имплентить флоу через nestedFragments и childFragmentManager?

а если например инжектить в презентер какой то интерфейс, реализация которого имеет доступ к активити?

нет, я имею ввиду хранить скоупы (компоненты) в retained фрагментах

аргументируй?)

слишком сложный механизм доя такой простой задачи

а как будет связан жц retained фрагмента с жц флоу?

самым что ни наесть образом
будет жить, пока жив родительский флоу-фрагмент, причём сквозь смену конфигурации

не соглашусь:
- во первых это абсолютно не сложно, если у тебя уже затянута rxjava. это легче чем sdkшный код писать
- во вторых, если приложение совсем маленькое, может там и вообще никакая архитектура не нужна?

сложно - понятие относительное

+ маленькие приложения имеют свойство становиться большими