Gradle buildType / productFlavor utilizando inesperado buildConfigField
Dada la siguiente configuración:
productFlavors { normal { applicationId "com.app" } mock { applicationId "com.app.mock" } } buildTypes { debug { productFlavors.normal.buildConfigField "boolean", "mockMode", "false" productFlavors.mock.buildConfigField "boolean", "mockMode", "true" } release { productFlavors.normal.buildConfigField "boolean", "mockMode", "false" // Release should never point to mocks. Ever. productFlavors.mock.buildConfigField "boolean", "mockMode", "false" } }
- Eclipse utiliza la variable PATH antigua para ejecutar el proceso de línea de comandos en la tarea Gradle?
- Prueba de una biblioteca de Android con Robolectric
- SignedConfigs me da un error de Lint en build.gradle después de actualizar a v22
- Es groovy un lenguaje de desarrollo potencial para Android
- Gradle define el valor de la ruta absoluta para un archivo de almacén de claves
Me habría esperado BuildConfig.mockMode = true;
, Sin embargo, esta es la configuración de compilación resultante:
public final class BuildConfig { public static final boolean DEBUG = Boolean.parseBoolean("true"); public static final String APPLICATION_ID = "*****"; public static final String BUILD_TYPE = "debug"; public static final String FLAVOR = "mock"; public static final int VERSION_CODE = 1; public static final String VERSION_NAME = "1.0"; // Fields from product flavor: mock public static final boolean mockMode = false; }
De una pequeña investigación / depuración, me di cuenta de que si cambio el valor para el sabor del producto en el buildType de la versión realmente actualiza el valor BuildConfig.mockMode
, a pesar de tener mockDebug
seleccionado como mi variante de construcción.
Ya tengo una mejor solución para lograr lo que quiero hacer, así que sólo estoy buscando una respuesta que me ayude a entender por qué Gradle está actuando de esta manera sobre la base de la configuración, para ayudarme a entender más de lo que está haciendo.
- Cómo configurar Android Studio proyecto desde cero que me permite utilizar groovy
- Grails / Gradle prueba falla en CI no localmente
- Groovy Android y libgdx
- Groovy CompileStatic en Android desordena Groovy Truth
- Grails save () Objeto de dominio en realidad hace una selección?
- Cómo definir y utilizar una constante en el script de compilación de Gradle (Android)?
- Ejecución de scripts de Groovy incrustados en Java en tiempo de ejecución para Android
- Tarea personalizada de Android Gradle por variante
Podría extraer la lógica para decidir el valor real del campo BuildConfig en un método propio. De esta manera, la configuración DSL tiene una sola línea. Parece algo como esto (no probado – esperar errores de sintaxis):
buildTypes { applicationVariants.all { variant -> variant.buildConfigField "boolean", "mockMode", mockMode(variant) } } def mockMode(variant) { //Return true or false depending on variant.buildType and variant.productFlavors }
Bastante fácil de entender una vez que se ejecuta con esta configuración:
buildTypes { debug { println("debug!") } release { println("release!") } }
Lo que verás en el registro de compilación es:
Information:Gradle tasks [:app:assembleOneDebug] debug! release! :app:preBuild UP-TO-DATE ...
Esto significa que las 4 líneas de su código se ejecutan, por lo tanto, las únicas líneas efectivas son las últimas 2:
productFlavors.normal.buildConfigField "boolean", "mockMode", "false" productFlavors.mock.buildConfigField "boolean", "mockMode", "false"
Lo que lleva a su BuildConfig
tener:
public static final boolean mockMode = false;
- Canvas.drawBitmap () se ralentiza intermitentemente, causando flashes blancos
- Cocos2D OR libgdx para el desarrollo de juegos Android