Build types

Los build types representan formas de construir la misma app según contexto técnico. Los clásicos son debug y release, pero podés tener otros si tu flujo lo justifica.

buildTypes {
    getByName("debug") {
        applicationIdSuffix = ".debug"
        versionNameSuffix = "-debug"
    }
    getByName("release") {
        isMinifyEnabled = true
        isShrinkResources = true
        proguardFiles(
            getDefaultProguardFile("proguard-android-optimize.txt"),
            "proguard-rules.pro"
        )
    }
}

Product flavors

Los flavors modelan variantes funcionales o de negocio: staging, producción, demo, país, cliente, marca o entorno.

flavorDimensions += "env"
productFlavors {
    create("dev") {
        dimension = "env"
        buildConfigField("String", "BASE_URL", '"https://dev.api.com"')
    }
    create("prod") {
        dimension = "env"
        buildConfigField("String", "BASE_URL", '"https://api.com"')
    }
}

Idea importanteBuild types y flavors resuelven problemas distintos. No uses sabores para cosas que en realidad son settings de debug/release, ni build types para modelar entornos de negocio.

Cómo se combinan

Gradle combina flavors y build types. Si tenés dev y prod, más debug y release, obtenés cuatro variantes. Eso puede ser poderoso, pero también multiplicar complejidad.

Casos reales

  • staging/prod para distintos backends.
  • demo/full para distribución limitada.
  • brandA/brandB para white-label.
  • internal/public para builds de testing interno.

AtenciónSi una decisión puede resolverse en runtime con Remote Config o configuración remota, no siempre conviene convertirla en flavor. Más variantes implican más combinaciones para build, test y soporte.

Cierre

Las variantes son una herramienta muy útil cuando están bien modeladas. En la siguiente lección vemos cómo centralizar configuración y dependencias para que un proyecto grande no termine lleno de duplicación.