web-dev-qa-db-ja.com

Android=

私のAndroidアプリ、およびの多くのフレーバーがあり、1つを除くすべてに同じキーを使用したい。別のキー。

たった1種類のアプリのsigningConfigをオーバーライドするにはどうすればよいですか（ただし、同じビルドタイプ内、たとえば「リリース」）？

  • デフォルトでは、すべてのビルドでメインリリース構成を使用したいと思います。
  • 1つのフレーバーのみをオーバーライドしたい
  • 単一のgradlew assembleReleaseコマンドですべてのリリースビルドを実行できるようにしたい

現在、120種類以上のフレーバーがあり、成長しているため、この最後のポイントは重要です。すべてのフレーバーを個別にカスタマイズするには、多くの追加作業が必要です。

私が試した関連記事：

単一のビルドタイプの異なるキーで署名された複数のビルドを作成する

  • これには、各フレーバーの構成が必要です
  • とにかくカスタムsigningConfigを使用していないようです

gradleで製品フレーバーに署名する

  • 受け入れられた解決策が機能しない（私にとって）
  • コメント によると、これはbuildTypesの中にproductFlavorsを置くことで可能ですが、これを行う方法がわかりません。

Gradle製品フレーバーのデバッグ構成のデバッグ

全体として、各ソリューションでは、カスタム構成ではなく、デフォルトのリリース構成が引き続き使用されているようです。

私のbuild.gradleの重要な部分は次のようになります。

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

Gradle Plugin User Guide は次のことができると言っています：

各Android.productFlavors.*.signingConfigオブジェクトを個別に設定して、各リリースパッケージが独自のSigningConfigを使用するようにします。

これは、この回答（ Gradle製品フレーバーのデバッグ構成のデバッグ ）およびこのブログ投稿（ Gradleを使用したAndroidアプリの複数のエディションのビルド ）で実証されています。

ただし、各フレーバーに個別のsigningConfig行を指定することはうまくスケールしないため、質問の範囲外でした。残念ながら、提供された回答はどれもsigningConfigを正しくオーバーライドする方法を示していませんでした。

トリックは、この回答（ gradleで現在選択されているビルドバリアントを取得する方法 ）に由来し、ビルドバリアント（および拡張機能によってフレーバー）をループする方法を示しています。

私のソリューションでは、ループを使用して、フレーバーごとにsigningConfigを設定しますが、そのための個別の行はありません。これは完璧にスケーリングします。 「オーバーライド」は、ループ後のカスタム構成を指定する1行で実行されます。

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
19
Richard Le Mesurier

下記のコードは、製品フレーバーでsigningConfigが指定されていない場合、デフォルトのsigningConfigとしてrelease1を使用します。

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

これが機能するかどうかは100％わかりませんが、新しいビルドタイプを作成したいとは思いません。これにより、すべてのフレーバーに対して新しいビルドバリアントが作成されます。本当に1つのフレーバーで "default config"をオーバーライドしたい場合:)

このコードはテストされていませんが、これに沿って何かを行うことができるはずです：

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

1
pjco

1つのアイデアは、カスタムsigninconfigを使用するかどうかを決定するためにプロジェクトプロパティを使用することです。

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

次に、カスタムフレーバーを作成するには、次を実行します。

gradle assembleCustomRelease -Pcustom=true
0
Arnaud

BuildTypesでsigningconfigsを定義する必要があります。デバッグビルドタイプにカスタム署名設定を追加するか、カスタムビルドタイプを作成します

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

Gradleは各ビルドタイプのフレーバーを作成し、buildTypeに応じてフレーバーはそれぞれのsigninconfigを使用します。上記のbuild typeの構成で、「Apple」フレーバーを検討してみましょう。 GradleはApple専用に次のビルドバリアントを作成します

  • appledebug->カスタム署名設定
  • applecustom->カスタム署名設定

  • applerelease->リリース署名設定

    それぞれのビルドバリアントを選択して、アプリケーションを実行できます

フレーバーに署名構成を追加する

productFlavors {
    def customSigningConfig = signingConfigs.custom

    custom {
        ...
        signingConfig customSigningConfig
        ...
    }

フレーバーを宣言する前に、signingConfigsを宣言する必要があります。

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

0
3xplore

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