У нас в андроиде есть флейворы. Это такой механизм разделения сборок. Каждый знает, что это для того, чтобы всякие там dev/qa/prod, gms/hms, free/paid, driver/rider разделять. Гугл так это и рекламирует. К слову, есть ещё билд тайпы, которые не отличаются, буквально, ничем, но это совсем другая история.
Зачем они нужны? Якобы упрощают переключение между разными типами сборок разработчикам и для кастомизации настроек этих сборок, в том числе source сеты, ресурсы, конфиги, что угодно в общем-то.
А что если я скажу, что у нас уже есть механизм контроля того, что в сборку попадёт или не попадёт? Зависимости между модулями! Заводим application модули для разных типов сборок, подключаем соответствующие модули, реализующие отличающуюся функциональность, и всё. Чуть больше кода для конфигурации, в миллион раз меньше проблем.
Флейворы - это лекарство, которое хуже болезни. Это всегда какой-то быстрый костыль, который сразу же начинает работать против тебя.
Почему? Хотя бы из-за влияния на конфигурацию и сборку. Представим что у нас 100 грэдл тасок, значит с дебаг и релиз билд тайпами их будет 200, с dev/prod флейворами их будет 400, с gms/hms их будет 800. И так далее. И они с разными суффиксами, ну то есть буквально разные таски. И что? - Спросите вы. Ну, например, кэш между ними так себе переиспользуется. То что ты собрал dev сборку никак тебе не облегчает prod сборку сразу после неё. Gradle с нуля её собирает, несмотря на то, что отличаются они, например, только одной строкой серверного урла, конфигурация же поменялась. Ну а конфигурировать 800 тасок тоже чуть подольше чем 100, как вы понимаете.
Суперпозиции билд тайпов и флейворов называются вариантами. Что касается лёгкости переключения между вариантами, то тут тоже есть вопросики. Как только вы переключаетесь в студии на другой вариант, то она сразу же начинает игнорировать всё, что использовалось в других вариантах, код не проверяется, рефактор не работает, он просто не участвует в индексировании. Эту хрупкую конструкцию очень неприятно поддерживать. А ещё, что если я скажу что переключение между вариантами у нас уже есть? Там где вы выбираете какую run конфигурацию (app модуль) запустить.
Не используйте флейворы на проектах больше хелоуворлда ✋. DI и зависимости между модулями спокойно решают ту же самую задачу, причём гораздо более явно. И ладно ещё если у вас один флейвор, и тот в app модуле - это терпимо, но когда их больше и они на библиотечные модули растекаются, то это уже перебор. Хочу развидеть как использовались флейворы на всех проектах, где я работал.