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