Las variantes de compilación en Android Studio son la respuesta a un dilema que conoce cualquiera que haya pensado en lanzar una aplicación. Pongamos el caso clásico: tienes una idea brillante y dudas entre sacar una versión gratuita con anuncios o una de pago sin publicidad. La tentación de crear dos proyectos separados y copiar código de un lado a otro es enorme, pero ahí empieza el caos. Gracias a Gradle, todo se gestiona desde un único sitio, evitando que el proyecto acabe siendo imposible de mantener.
El truco está en combinar reglas de empaquetado con características del producto. Al mezclar los tipos de compilación con las variantes, salen versiones concretas que sirven para necesidades muy distintas. Por ejemplo, una app de depuración para el equipo de QA y, al mismo tiempo, una versión final pulida para los usuarios de Google Play, sin tener que mover archivos a mano.
Build Types y Product Flavors, los dos pilares
Los Build Types definen cómo se empaqueta y compila la aplicación. Android Studio ya trae dos por defecto: debug y release. La primera es la del día a día, con herramientas de depuración y una clave genérica para instalarla rápido en cualquier dispositivo de prueba. La de release es la que va a la tienda, donde se activa la optimización de código con ProGuard o R8 para que la app pese menos y sea más difícil de piratear. Si necesitas más, puedes añadir una variante de staging tocando el bloque buildTypes del archivo build.gradle.kts. Una propiedad muy práctica aquí es applicationIdSuffix, que permite tener la versión de desarrollo y la de producción en el mismo móvil sin que se pisen.
Los Product Flavors son donde la cosa se pone interesante. Sirven para crear versiones con funcionalidades diferentes, ideal si quieres una «Lite» y una «Pro». Cada flavor tiene que pertenecer obligatoriamente a una dimensión, usando flavorDimensions, o Gradle te lanza un error. Lo bueno es que heredan las propiedades de defaultConfig pero pueden sobrescribir valores concretos, como el applicationId para que cada versión sea una app independiente en la Play Store.
Link affiliatoCombinaciones, recursos y firma segura
Cuando hay más de una dimensión, Gradle genera un producto cartesiano con todas las combinaciones posibles, dando nombres como demoDebug o fullRelease. Si alguna no tiene sentido, el bloque variantFilter elimina las variantes que sobran y agiliza la sincronización.
Para que cada versión tenga sus propios iconos, textos o lógica, entran en juego los source sets. Lo común vive en main, pero se pueden crear carpetas con el nombre exacto del flavor o del build type. Gradle fusiona los recursos siguiendo una jerarquía clara: primero la variante completa (src/demoDebug/), luego el build type (src/debug/), después el flavor (src/demo/) y al final main. Eso sí, cuidado con el código Java o Kotlin, porque no se puede definir la misma clase en dos carpetas que se fusionen sin provocar un error de clase duplicada.
También se pueden controlar las dependencias específicas. En vez de implementation, usar demoImplementation hace que una librería solo entre en la variante demo. Y si una librería no tiene el build type «staging», matchingFallbacks le dice a Gradle que use release en su lugar, mientras missingDimensionStrategy resuelve las dimensiones que falten.
El último punto, y crítico, es la seguridad. Para las versiones de lanzamiento hay que configurar signingConfigs, pero lo recomendable es no escribir las contraseñas directamente en el archivo de Gradle. Mejor leerlas desde variables de entorno o archivos de propiedades locales que nunca se suban al repositorio de Git, garantizando así que cada versión llegue al usuario con la configuración prevista.
Link affiliatoFuente
Imagen: androidayuda.com