Firma dei sapori del prodotto con gradel

Sto cercando di migrare i miei progetti a gradle. Uno dei miei progetti ha più sapori di prodotto e ognuno di essi deve essere firmato con un firmingConfig diverso nella sua versione di rilascio. Quindi questo è quello che ho provato finora:

buildscript { ... } apply plugin: 'android' android { compileSdkVersion 17 buildToolsVersion '17' signingConfigs { flavor1 { storeFile file("keystore") storePassword "secret" keyAlias "aliasForFlavor1" keyPassword "secretFlavor1" } flavor2 { storeFile file("keystore") storePassword "secret" keyAlias "aliasForFlavor2" keyPassword "secretFlavor2" } } productFlavors { flavor1 { signingConfig signingConfigs.flavor1 } flavor1 { signingConfig signingConfigs.flavor2 } } } dependencies { ... } 

Quando gradle build ho un groovy.lang.MissingFieldException e il seguente messaggio di errore:

  • come leggere il valore da string.xml in android?
  • qual è il modo corretto per aggiornare dbll dbllite?
  • come creare l'effetto ripple per il pre-lollipop
  • Come autenticare un'applicazione mobile senza username e password?
  • trascina, zoom immagini senza android di matrix
  • Viewpager, cursore e frammento
  •  No such field: signingConfigs for class: com.android.build.gradle.internal.dsl.GroupableProductFlavorFactory 

    Quindi suppongo che il prodottoFlavors. * Parte dello script di gradle non è il posto giusto per mettere le configurazioni di firma del codice.

  • Esecuzione non rioutput per il task ': app: dexDebug'. com.android.ide.common.process.ProcessException: org.gradle.process.internal.ExecException
  • Android: causato da: android.os.NetworkOnMainThreadException
  • come invertire la direzione di ViewPager da sinistra a destra ordine?
  • È ansible, in linea di principio, che un dispositivo Android si interface con un iPhone tramite Bluetooth / GameKit?
  • Attività di finitura in BackStack - Android
  • Qual è il modo migliore per scaricare i file dalla networking in modo programmato in android?
  • 3 Solutions collect form web for “Firma dei sapori del prodotto con gradel”

    Per la guida dell'utente , sono supportti i firmingConfigs per i sapori.

    Il problema qui ha a che fare con l'ambito dell'object signingConfigs. Ho appena assegnato ad una variabile all'interno del block flavor1 , ma al di fuori del block aroma flavor1 per risolvere il problema:

     productFlavors { def flavor1SigningVariable = signingConfigs.flavor1 flavor1 { ... signingConfig flavor1SigningVariable ... } 

    È ansible dichiarare la signing config per each flavor in buildType . Ecco il mio file gradle per il rilascio dei sapori di firma con diversi negozi di chiavi.

     android { signingConfigs { configFirst { keyAlias 'alias' keyPassword 'password' storeFile file('first.keystore') storePassword 'password' } configSecond { keyAlias 'alias' keyPassword 'password' storeFile file('second.keystore') storePassword 'password' } } compileSdkVersion 23 buildToolsVersion "23.0.2" defaultConfig { minSdkVersion 14 targetSdkVersion 23 } productFlavors{ flavor1 { applicationId "com.test.firstapp" } flavor2 { applicationId "com.test.secondapp" } } buildTypes { release { productFlavors.flavor1.signingConfig signingConfigs.configFirst productFlavors.flavor2.signingConfig signingConfigs.configSecond minifyEnabled true proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro' } } } 

    block buildTypes dovrebbe essere posto dopo il block productFlavors , voglio dire l'ordine è importnte.

    Il plugin gradle per android support solo la firma per tipo di build, non per sapore. La ragione di questo è che una qualsiasi variante (tipo build + flavors) può essere firmata solo da una chiave, ma può essere una combinazione di diversi gruppi di sapori. Ad esempio i tuoi gruppi di sapori potrebbero essere la CPU (x86 / arm) e la versione (gratuita / pagata), cioè quattro varianti diverse proprio lì.

    La soluzione che stai cercando è quella di creare tipi di build separati per le diverse versioni di rilascio. Ad esempio, i tipi di build possono essere il debug , il release , la release-beta , come questo:

     ... android { ... buildTypes { debug { signingConfig signingConfigs.debug } release { signingConfig signingConfigs.release } release-beta { initWith release signingConfig signingConfigs.release-beta } } } 

    L' initWith sopra dice semplicemente che il release-beta dovrebbe essere una copia del tipo di release , solo firmato con una chiave diversa.

    L'Android è un fan Android di Google, tutto su telefoni Android, Android Wear, Android Dev e applicazioni Android Games e così via.