Gradle buildtype/productFlavor utilizzando inaspettato buildConfigField

Question

data la configurazione di seguito:

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" 
    } 
} 

mi sarei aspettato BuildConfig.mockMode = true;, tuttavia, questa è la risultante di configurazione di generazione:

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; 
} 

Da un po 'di ricerca/debug, mi sono reso conto che se cambio il valore per l'aroma del prodotto nel rilascio buildType in realtà aggiorna il valore BuildConfig.mockMode, nonostante abbia selezionato mockDebug come variante di build.

Ho già una soluzione migliore per ottenere quello che voglio fare, quindi sto solo cercando una risposta che mi aiuti a capire perché Gradle agisce in questo modo in base alla configurazione, per aiutarmi a capire di più di quello che sta facendo.

Answer 1

abbastanza facile da capire, una volta che si esegue con questa configurazione:

buildTypes { 
    debug { 
     println("debug!") 
    } 
    release { 
     println("release!") 
    } 
} 

Quello che vedrete nel registro build è:

Information:Gradle tasks [:app:assembleOneDebug] 
debug! 
release! 
:app:preBuild UP-TO-DATE 
... 

Ciò significa che tutte le 4 righe di codice è la tua eseguito, quindi le uniche linee efficaci sono gli ultimi 2:

productFlavors.normal.buildConfigField "boolean", "mockMode", "false" 
productFlavors.mock.buildConfigField "boolean", "mockMode", "false" 

che conduce al tuo BuildConfig avere:

public static final boolean mockMode = false; 

Answer 2

Si potrebbe estrarre la logica per decidere sul valore reale del campo BuildConfig in un metodo a sé stante. In questo modo, la configurazione DSL ha una sola riga. Sembra qualcosa del genere (non testato - si aspettano errori di sintassi):