Gradle подписывает ароматы с разными ключами на Android

Ответ 1

Gradle Руководство пользователя плагина говорит, что вы можете:

каждый пакет выпуска использует свой собственный SigningConfig, устанавливая каждый android.productFlavors.*.signingConfig объектов отдельно.

Это демонстрируется в этом ответе (Конфигурация отладки Debug на Gradle Атрибутах продукта) и этом сообщении в блоге (Создание нескольких версий Android-приложения с Gradle).

Однако указание отдельной строки SigningConfig для каждого аромата не очень хорошо масштабируется и выходит за рамки вопроса. К сожалению, ни один из предоставленных ответов не показал, как правильно правильно отредактировать SigningConfig.

Трюк пришел из этого ответа (Как получить выбранный вариант сборки в gradle?), в котором показано, как перебирать варианты сборки (и по расширению, ароматизаторы).

Мое решение использует цикл для установки SigningConfig для каждого аромата вместо отдельной строки для этого. Это очень хорошо. "Завершение" выполняется с помощью одной строки, которая задает пользовательскую конфигурацию после цикла.

Поместите следующий код внутри блока buildTypes.release:

// 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

Ответ 2

Нижеприведенный код будет использовать release1 как defaultConfig по умолчанию, если signConfig не указывается в цвете продукта.

приложение/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
    }
}

Ответ 3

Я не уверен на 100%, что это сработает, но я не думаю, что вы хотите создать новый тип сборки. Это создаст новый вариант сборки для каждого аромата. Когда на самом деле вам просто нужен один вкус, чтобы переопределить "конфигурацию по умолчанию":)

Этот код не проверен, но вы должны сделать что-то в этом роде:

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

Справка:
http://tools.android.com/tech-docs/new-build-system/user-guide#TOC-Product-Flavor-Configuration

Ответ 4

Вам нужно будет определить параметры подписи в ваших buildTypes. Добавьте настраиваемый скрипт подписи в свой тип сборки отладки или создайте собственный тип сборки

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

Gradle создаст аромат для каждого типа сборки, и в зависимости от типа buildType вкус будет использовать соответствующий signinconfig. С приведенной выше конфигурацией типа сборки давайте рассмотрим "яблочный" вкус. Gradle создаст следующие варианты сборки только для apple

• appledebug → настраиваемая конфигурация подписи
• applecustom → пользовательская настройка для подписания

• applerelease → версия для подписания подписки

  Вы можете выбрать соответствующий вариант сборки и запустить приложение

Добавление конфигурации подписи к аромату

productFlavors {
    def customSigningConfig = signingConfigs.custom

    custom {
        ...
        signingConfig customSigningConfig
        ...
    }

Вам нужно объявить свои подписи, прежде чем объявлять свои вкусы.

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

Ответ 5

Одной из идей может быть использование свойств проекта, чтобы определить, следует ли вам использовать или не использовать свой собственный signinconfig.

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

Затем, чтобы создать свой собственный вкус, вы запускаете:

gradle assembleCustomRelease -Pcustom=true

Ответ 6

tl; dr проходит через gradle.startParameter.taskNames "для поиска вкуса и изменения переменной.

Я делаю это для тестовых вариантов для приложения Vine, и это работает очень хорошо. Вы также можете использовать это, чтобы скомпилировать различные зависимости, не добавляя больше размеров аромата.

В вашем случае это будет выглядеть примерно так.

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