Definire buildconfigfield per un aroma specifico E buildType

Ho 2 sapori, diciamo Vaniglia e Cioccolato. Ho anche i tipi di build Debug e Release, e ho bisogno di Vanilla Release per avere un campo true, mentre le altre 3 dovrebbero essere false.Definire buildconfigfield per un aroma specifico E buildType

def BOOLEAN = "boolean" 
def VARIABLE = "VARIABLE" 
def TRUE = "true" 
def FALSE = "false" 

    VANILLA { 

     debug { 

      buildConfigField BOOLEAN, VARIABLE, FALSE 

     } 

     release { 

      buildConfigField BOOLEAN, VARIABLE, TRUE 

     } 


    } 

    CHOCOLATE { 
     buildConfigField BOOLEAN, VARIABLE, FALSE 
    }

Ho un errore, quindi suppongo che il trucco di debug e rilascio non funzioni. È possibile farlo?

fonte

2015-05-20 JesusS

perché stai ridefinendo booleano, vero e falso ... –

preferisco usa BOOLEAN, TRUE e FALSE piuttosto che "boolean", "true" e "false". Tuttavia non ha nulla a che fare con la domanda – JesusS

Vedere questa risposta: http://stackoverflow.com/a/26579662/10793 – Muxa

Loop le varianti e controllare i loro nomi:

productFlavors { 
    vanilla {} 
    chocolate {} 
} 

applicationVariants.all { variant -> 
    println("Iterating variant: " + variant.getName()) 
    if (variant.getName() == "chocolateDebug") { 
     variant.buildConfigField "boolean", "VARIABLE", "true" 
    } else { 
     variant.buildConfigField "boolean", "VARIABLE", "false" 
    } 
}

fonte

2015-05-27 15:06:37 Simas

Grazie mille! Devo ancora aspettare di dare la taglia fino a domani – JesusS

Questa soluzione ha una mancanza - si usano stringhe per determinare una variante di costruzione. Nel caso di un numero elevato di buildConfigFields, avrai un codice standard. Inoltre, non dovresti dimenticare di correggere i controlli dopo aver ribattezzato buildType o productFlavor –

Soluzione aggiunta https://stackoverflow.com/a/47199250/1228514 –

All'interno del sistema di generazione Gradle, buildTypes e productFlavors sono purtroppo due entità separate.

Per quanto ne so, per completare quello che si vuole raggiungere, si avrebbe bisogno di creare un altro sapore di costruzione in quanto tale:

buildTypes { 
     debug{} 
     release {} 
    } 

    productFlavors { 
     vanillaDebug { 
      buildConfigField BOOLEAN, VARIABLE, FALSE 
     } 
     vanillaRelease { 
      buildConfigField BOOLEAN, VARIABLE, TRUE 
     } 
     chocolate { 
      buildConfigField BOOLEAN, VARIABLE, FALSE 
     } 
    }

fonte

2015-05-21 08:39:03

Grazie per la risposta, questo è quello che temevo. Con questo approccio avrei 6 diverse build, giusto? vanillaDebugDebug, vanillaDebugRelease, vanillaReleaseDebug, vanillaReleaseRelease, chocolateDebug, chocolateRilease giusto? Penso che questa soluzione non sia adatta alle mie esigenze ma immagino che non ci sia una buona soluzione al problema – JesusS

Non è l'ideale, lo so, ma è il modo corretto di farlo al momento –

Ecco come ho risolto in questo modo:

def GAME_DIMENSION = "game" 
def BUILD_DIMENSION = "building" 

flavorDimensions GAME_DIMENSION, BUILD_DIMENSION 

productFlavors { 
    lollipop { 
     dimension BUILD_DIMENSION 
     minSdkVersion 21 
    } 

    normal { 
     dimension BUILD_DIMENSION 
    } 

    game_1 { 
     dimension GAME_DIMENSION 
     ext { 
      fields = [ 
        [type: 'String', name: 'TESTSTRING', values: [debug: 'debugstring', release: 'releasestring']], 
        [type: 'int', name: 'TESTINT', values: [debug: '1234', release: '31337']] 
      ] 
     } 
    } 

    game_2 { 
     dimension GAME_DIMENSION 
     ext { 
      fields = [] // none for game_2 
     } 
    } 
} 

applicationVariants.all { variant -> 

    // get the GAME dimension flavor 
    def game = variant.getProductFlavors() 
      .findAll({ flavor -> flavor.dimension == GAME_DIMENSION}) 
      .get(0) 

    println "Adding " + game.ext.fields.size() + " custom buildConfigFields for flavor " + variant.name 

    // loop over the fields and make appropriate buildConfigField 
    game.ext.fields.each { field -> 
     def fldType = field['type'] 
     def fldName = field['name'] 
     def fldValues = field['values'] 

     // get debug/release specific value from values array 
     def fldSpecificValue = fldValues[variant.getBuildType().name] 

     // add quotes for strings 
     if (fldType == 'String') { 
      fldSpecificValue = '\"' + fldSpecificValue + '\"' 
     } 

     println " => " + fldType + " " + fldName + " = " + fldSpecificValue 
     variant.buildConfigField fldType, fldName, fldSpecificValue 
    } 
}

(io non sono ancora stati in grado di determinare se o no t ext.fields esiste un sapore)

fonte

2016-10-05 14:37:02 xorgate

-1

productFlavors { 
    vanilla {} 
    chocolate {} 
} 

buildTypes { 
     release { 
      productFlavors.vanilla { 
       //your configuration for vanilla flavor with release buildType 
      } 
     } 
     debug { 
      productFlavors.chocolate{ 
       //your configuration for chocolate flavor with debug buildType 
      } 
     } 
    }

fonte

2017-04-05 13:47:53 Paha

Quando lo fai, prenderà l'ultima definizione che hai inserito. Quindi in questo caso verrà sempre compilato con debugCocolate. Quando cambi l'ordine in modo che la vaniglia sia definita sotto il cioccolato, lo prenderà sempre. Molto probabilmente questo non è il risultato desiderato. Anche se sarebbe bello se funzionasse così. – pl3kn0r

Ecco una soluzione senza difetta ho descritto sotto Simas answer

buildTypes { 
    debug {} 
    release {} 
} 

productFlavors { 
    vanilla { 
     ext { 
      variable = [debug: "vanilla-debug value", release: "vanilla-release value"] 
     } 
    } 
    chocolate { 
     ext { 
      variable = [debug: "chocolate-debug value", release: "chocolate-release value"] 
     } 
    } 
} 

applicationVariants.all { variant -> 
    def flavor = variant.productFlavors[0] 
    variant.buildConfigField "boolean", "VARIABLE", "\"${flavor.ext.variable[variant.buildType.name]}\"" 
}

fonte

2017-11-09 10:19:11

Definire buildconfigfield per un aroma specifico E buildType

risposta

Problemi correlati