Qué construimos con él
Toda app Flutter tiene una build de Gradle bajo su mitad Android, y deja de ser invisible en cuanto un producto necesita más de una variante. Product flavours para staging y producción, configuraciones de firma separadas, application ID por flavour, sobreescritura de recursos y los SDK nativos que la app arrastre.
Ahí es también donde viven los problemas incómodos: conflictos de dependencias entre plugins, reglas de minificación que eliminan algo que la reflexión necesitaba y fallos de compilación que solo ocurren en modo release.
Dónde encaja
Bajo el lado Android de nuestro trabajo móvil, estrechamente ligado a Kotlin cuando una app tiene código nativo, y a Fastlane, que dispara estas builds desde CI y no desde la máquina de un desarrollador.
Importa sobre todo en productos multiobjetivo. Una plataforma de marca blanca que produce muchas apps de marca desde una base de código es en realidad tanto un problema de configuración de Gradle como de Flutter: cada marca necesita su identificador, sus recursos y su identidad de firma, generados en vez de mantenidos a mano.
Cuándo lo recomendamos
No es opcional en Android; la única elección es si tratar la build como código. Nosotros sí: flavours declarados una vez y derivados, no copiados y pegados por marca.
Donde lo mantenemos al mínimo es en plugins de Gradle a medida y grafos de tareas hechos a mano. Son potentes y son también lo que nadie del equipo quiere depurar dos años después, así que recurrimos a ellos solo cuando un problema real lo exige.