web-dev-qa-db-fra.com

Gradle signant des saveurs avec différentes clés sur Android

J'ai plusieurs versions de mon Android et je veux que toutes sauf une utilisent la même clé. Il y en a une qui doit utiliser une clé différente.

Comment remplacer le signingConfig pour seulement 1 version de l'application (mais dans le même type de build, par exemple "release")?

  • Je voudrais que toutes les versions utilisent par défaut la configuration de la version principale.
  • Je veux seulement remplacer 1 saveur
  • Je veux pouvoir exécuter toutes les versions avec une seule gradlew assembleRelease commande

Ce dernier point est important car j'ai actuellement plus de 120 saveurs et cultures différentes. Afin de personnaliser chaque saveur individuellement, c'est beaucoup de travail supplémentaire.

Articles connexes que j'ai essayés:

Produire plusieurs builds signés avec différentes clés à partir d'un seul type de build

  • cela nécessite une configuration pour chaque saveur
  • il ne semble pas utiliser mon signingConfig personnalisé de toute façon

Signature des saveurs des produits avec gradle

  • la solution acceptée ne fonctionne pas (pour moi)
  • selon n commentaire c'est possible en mettant buildTypes dans le productFlavors mais je ne comprends pas comment faire ça.

Debug Signing Config on Gradle Product Flavors

Dans l'ensemble, chaque solution semble toujours utiliser la configuration de version par défaut, au lieu de ma configuration personnalisée.

Parties importantes de mon build.gradle ressemble à ca:

signingConfigs {
    releaseConfig {
        storeFile file('key')
        storePassword "pass"
        keyAlias "alias"
        keyPassword "pass"
    }

    custom {
        storeFile file('custom_key')
        storePassword "pass"
        keyAlias "alias"
        keyPassword "pass"
    }
}

productFlavors {
    Apple {
        applicationId "demo.Apple"
    }
    banana {
        applicationId "demo.banana"
    }

    // def customConfig = signingConfigs.custom
    custom {
        applicationId "custom.signed.app"
        // signingConfig customConfig
    }
 }


buildTypes {
    debug {
        applicationIdSuffix ".debug"
    }
    release {
         signingConfig signingConfigs.releaseConfig
         // productFlavors.custom.signingConfig signingConfigs.custom
    }
}
androidgradleandroid-gradlecode-signing
41
Richard Le Mesurier

Le Gradle Plugin User Guide dit que vous pouvez:

que chaque package de versions utilise son propre SigningConfig en définissant chaque Android.productFlavors.*.signingConfig objets séparément.

Ceci est démontré dans cette réponse ( Debug Signing Config on Gradle Product Flavors ) et ce billet de blog ( Building Multiple Editions of an Android App with Gradle ).

Cependant, la spécification d'une ligne signingConfig distincte pour chaque saveur n'est pas bien adaptée et était hors de portée de la question. Malheureusement, aucune des réponses fournies n'a montré comment remplacer correctement un signingConfig correctement.

L'astuce est venue de cette réponse ( Comment obtenir la variante de construction actuellement choisie dans gradle? ) qui montre comment parcourir les variantes de construction (et par extension, les saveurs).

Ma solution utilise une boucle pour définir le signingConfig sur chaque saveur au lieu d'avoir une ligne distincte pour cela. Cela évolue parfaitement bien. Le "remplacement" se fait avec une seule ligne qui spécifie la configuration personnalisée après la boucle.

Placez le code suivant dans le buildTypes.release bloquer:

// loop over all flavors to set default signing config
productFlavors.all { flavor ->
    flavor.signingConfig signingConfigs.releaseConfig
}
// override default for single custom flavor
productFlavors.custom.signingConfig signingConfigs.custom
19
Richard Le Mesurier

Le code ci-dessous utilisera release1 comme signature par défautConfig si la signatureConfig n'est pas spécifiée dans la version du produit.

app/build.gradle

signingConfigs {
    debug {
        storeFile file("/home/.../debugkeystore.jks")
        storePassword "..."
        keyAlias "..."
        keyPassword "..."
    }
    release1 {
        storeFile file("/home/.../testkeystore1.jks")
        storePassword "..."
        keyAlias "..."
        keyPassword "..."
    }
    release2 {
        storeFile file("/home/.../testkeystore2.jks")
        storePassword "..."
        keyAlias "..."
        keyPassword "..."
    }
    release3 {
        storeFile file("/home/.../testkeystore3.jks")
        storePassword "..."
        keyAlias "..."
        keyPassword "..."
    }
}

defaultConfig {
    applicationId "com.example.signingproductflavors"
    minSdkVersion 15
    targetSdkVersion 24
    versionCode 1
    versionName "1.0"
    testInstrumentationRunner "Android.support.test.runner.AndroidJUnitRunner"
    signingConfig signingConfigs.release1
}

buildTypes {
    release {
        minifyEnabled false
        proguardFiles getDefaultProguardFile('proguard-Android.txt'), 'proguard-rules.pro'
    }
    debug { 
        signingConfig signingConfigs.debug
    }
}

productFlavors {
    blocks {
        applicationId "com.example.blocks"
        resValue 'string', 'APP_NAME', "Blocks"
    }
    cloud {
        applicationId "com.example.cloud"
        resValue 'string', 'APP_NAME', "Cloud"
        signingConfig signingConfigs.release2
    }
    deck {
        applicationId "com.example.deck"
        resValue 'string', 'APP_NAME', "Deck"
        signingConfig signingConfigs.release3
    }
}
10
Ashwin

Je ne suis pas sûr à 100% que cela fonctionnera, mais je ne pense pas que vous souhaitiez créer un nouveau type de build. Cela créerait une nouvelle variante de construction pour chaque saveur. Quand vraiment vous voulez juste qu'une saveur écrase une "configuration par défaut" :)

Ce code n'est pas testé mais vous devriez pouvoir faire quelque chose dans le sens de ceci:

signingConfigs {
    normal {
        storeFile file('key')
        storePassword "pass"
        keyAlias "alias"
        keyPassword "pass"
    }

    custom {
        storeFile file('custom_key')
        storePassword "pass"
        keyAlias "alias"
        keyPassword "pass"
    }
}

    /**
     *  defaultConfig is of type 'ProductFlavor'.
     *
     *  If we need to use a different signing key than the default,
     *  override it in the specific product flavor.
     */

    defaultConfig {
        versionCode 123
        versionName '1.2.3'
        minSdkVersion 15

        def standardSigningConfig = signingConfigs.normal

        buildTypes{
            release {
               signingConfig standardSigningConfig 
               zipAlign true
               // ...
            }
            debug { 
               //not sure you need this node
            }  
        }
    }


productFlavors {

    def customConfig = signingConfigs.custom
    def standardSigningConfig = signingConfigs.normal

    Apple {
        applicationId "demo.Apple"
    }
    banana {
        applicationId "demo.banana"
    }
    custom {
        applicationId "custom.signed.app"
        signingConfig customConfig
    }
}

Référence:
http://tools.Android.com/tech-docs/new-build-system/user-guide#TOC-Product-Flavor-Configuration

1
pjco

Une idée pourrait être d'utiliser les propriétés du projet afin de déterminer si vous devez ou non utiliser votre signinconfig personnalisé.

if (project.hasProperty('custom')) {
    Android.signingConfigs.release = customSigningConfig
} else {
    //should use the default
}

Ensuite, pour créer votre saveur personnalisée, vous exécutez:

gradle assembleCustomRelease -Pcustom=true
0
Arnaud

Vous devez définir les signatures de configuration dans vos buildTypes. Ajoutez une configuration de signature personnalisée à votre type de build de débogage ou créez un type de build personnalisé

    buildTypes {
        debug {
            applicationIdSuffix ".debug"
             signingConfig signingConfigs.custom
        }
        custom {
            applicationIdSuffix ".custom"
             signingConfig signingConfigs.custom
        }
        release {
             signingConfig signingConfigs.releaseConfig
        }
}

Gradle créerait une saveur pour chaque type de build et selon le buildType, la saveur utiliserait le signinconfig respectif. Avec la configuration de type de construction ci-dessus, considérons la saveur "Apple". Gradle créerait les variantes de construction suivantes uniquement pour Apple

  • appledebug -> configuration de signature personnalisée
  • applecustom -> configuration de signature personnalisée

  • applerelease -> libération de la configuration de signature

    Vous pouvez sélectionner la variante de construction respective et exécuter votre application

Ajout d'une configuration de signature à la saveur

productFlavors {
    def customSigningConfig = signingConfigs.custom

    custom {
        ...
        signingConfig customSigningConfig
        ...
    }

Vous devez déclarer votre signatureConfigs avant de déclarer vos saveurs.

https://code.google.com/p/Android/issues/detail?id=64701

0
3xplore

tl; dr parcourez "gradle.startParameter.taskNames" pour rechercher la saveur et modifier la variable.

Je le fais pour les variantes de test pour l'application Vine et cela fonctionne très bien. Vous pouvez également l'utiliser pour compiler différentes dépendances sans ajouter plus de dimensions de saveur.

Cela ressemblerait à quelque chose comme ça dans votre cas.

            //root of buil.gradle OR probably inside buildTypes.release
            def signType = signingConfigs.normal;
            //You can put this inside builTypes.release or any task that executes becore
            def taskNames = gradle.startParameter.taskNames;
                taskNames.each { String name ->
                    if (name.contains("customFlavor")) {
                        signType = signingConfigs.custom
                    }
                }
            buildTypes{
                release {                   
                    signingConfig signType
                }
            }
0
Edison