Что мы на нём делаем
У каждого Flutter-приложения под Android-половиной лежит сборка на Gradle, и она перестаёт быть невидимой в тот момент, когда продукту нужен больше чем один вариант. Флейворы для стейджинга и продакшена, отдельные конфигурации подписи, свои application ID, переопределения ресурсов и любые нативные SDK, которые тянет приложение.
Там же живут и неудобные проблемы: конфликты зависимостей между плагинами, правила минификации, вырезающие то, что было нужно рефлексии, и сборки, падающие только в release-режиме.
Где он нужен
Под Android-частью нашей мобильной разработки, в тесной связке с Kotlin, когда в приложении есть нативный код, и с Fastlane, который запускает эти сборки из CI, а не с машины разработчика.
Больше всего он значит на многоцелевых продуктах. White-label платформа, выпускающая множество брендированных приложений из одной кодовой базы, — это задача конфигурации Gradle не меньше, чем задача Flutter: каждому бренду нужны свои идентификатор, ассеты и подпись, причём генерируемые, а не поддерживаемые вручную.
Когда мы его рекомендуем
Для Android он не опционален; выбор только в том, относиться ли к сборке как к коду. Мы относимся: флейворы объявляются один раз и выводятся, а не копируются под каждый бренд.
Минималистичны мы в собственных Gradle-плагинах и хитрых графах задач. Они мощные — и они же то, что через два года никто в команде не хочет отлаживать, поэтому мы беремся за них, только когда этого требует настоящая проблема.