Clase 06 - Variables en Desarrollo y Producción en Android

Rentabiliza tu app con anuncios

Cuando desarrollamos apps Android, separar variables entre desarrrollo: debug y producción: release es obligatorio. Especialmente si integras servicios externos como:

• Google AdMob (Rentabiliza tu app con anuncios)
• APIs
• Firebase
• URLs backend
• Tokens

Un error común de principiantes es usar las mismas variables en desarrollo y producción. Eso puede provocar:

• Bloqueos de cuenta en AdMob
• Publicidad inválida
• Bugs en producción
• Datos mezclados entre testing y usuarios reales

¿Qué es build.gradle.kts?

build.gradle.kts es el archivo donde Android configura cómo construir tu aplicación. Aquí defines:

• versión
• dependencias
• plugins
• SDK
• variables
• Build Types

Podemos verlo como:

El cerebro de compilación de Android.

¿Qué son los Build Types en Android?

Los Build Types en Android son modos de compilación que permiten crear distintas versiones de una misma app.

Por defecto existen:

• debug → para desarrollo y pruebas
• release → para producción y usuarios reales

La app puede comportarse diferente según el Build Type, por ejemplo usando logs y anuncios TEST en debug, y optimización y anuncios reales en release.

Caso real: Google AdMob

Google NO permite mostrar anuncios reales a desarrolladores o testers.
Por eso, AdMob proporciona IDs especiales para pruebas.

En tu proyecto Android necesitas configurar correctamente Google AdMob teniendo claros los Build Types (debug y release) y el uso de variables de configuración.

Para esta integración utilizaremos:

• Build Types: debug, release
• Variables: buildConfigField, manifestPlaceholders

Configuración en build.gradle.kts

Dentro de build.gradle.kts podemos configurar distintos comportamientos según el entorno de ejecución de la app.

buildTypes {  
    debug {  
        buildConfigField("String", "ADMOB_BANNER_ID", "\"ca-app-pub-3940256099942544/6300978111\"")  
        manifestPlaceholders["admob_app_id"] = "ca-app-pub-3940256099942544~3347511713"  
    }  
    release {  
        buildConfigField("String", "ADMOB_BANNER_ID", "\"ca-app-pub-8513987061423192/1269405000\"")  
        manifestPlaceholders["admob_app_id"] = "ca-app-pub-8513987061423192~9661079000"  
    }  
}

Usando variables en Kotlin

Después accedemos a esas variables mediante BuildConfig.

Ejemplo:

adUnitId = BuildConfig.ADMOB_BANNER_ID

Esto permite:

• código limpio
• menos errores
• separar testing de producción
• escalar proyectos fácilmente

Variables en AndroidManifest.xml

También podemos usar placeholders:

<meta-data    android:name="com.google.android.gms.ads.APPLICATION_ID"    android:value="${admob_app_id}"/>

Así evitamos hardcodear valores directamente.

Resultado final

Desarrollo (debug)

• anuncios test
• entorno seguro
• pruebas locales

Producción (release)

• anuncios reales
• monetización activa
• usuarios finales

Ventajas de trabajar así

• Mejor organización
• Código más profesional
• Menos errores en producción
• Compatible con CI/CD
• Ideal para monetizar apps Android

Conclusión

Separar variables entre debug y release es una práctica básica pero extremadamente importante.

Muchos problemas de monetización en Android ocurren por no entender esto.

Si quieres crear apps profesionales:

• aprende Build Types
• separa entornos
• automatiza configuraciones

---

🎁🔥 Acceso a la Clase Completa de Android SaaS

📱 Android Profesional: DEV vs PRODUCCIÓN 🚀

📚 Acceso a:
✅ Clase completa
✅ Código fuente
✅ Materiales
✅ Recursos Android
✅ Proyecto real

📲 Acceso directo aquí:
https://wa.me/51970142637

---

Autor: Anibal Copitan ( Contactar con Anibal Copitan )