web-dev-qa-db-ja.com

ビルドタイプと製品フレーバーを構成する方法は？

この回答に基づいて https://stackoverflow.com/a/27908019/5156317 フォローアップの質問があります：製品のフレーバーを表すアプリの違いは何ですか？私はこれを次のようなXCodeセットアップと比較しようとしています：

  • テストバックエンドを使用する開発アプリ
  • 本番バックエンドを使用する開発アプリ
  • テストバックエンドを使用するテストアプリ（エンタープライズディストリビューション）
  • 本番バックエンドを使用するテストアプリ（エンタープライズディストリビューション
  • 本番バックエンドを利用したライブアプリ（アプリストア配信）

Androidセットアップについての私の考え：

buildTypes：debug_test debug_production //どのデバイスリリースでも署名されていないアプリが可能であるため、エンタープライズアプリは必要ありません

フレーバー：myApp

ご協力ありがとうございました！

androidandroid-gradle-plugincontinuous-integrationbuild.gradlefastlane
13
Fahim

さて、異なるバックエンドを使用するために、debugとreleaseより多くのビルドタイプを指定することはありません。代わりに、次のテクニックのいくつかを使用します。

  • より多くのフレーバー、
  • カスタムビルド構成フィールド（ドキュメント ここ ）、
  • 複数の製品フレーバーを組み合わせます（ドキュメント ここ ）。

BuildConfigクラスを使用して、アプリケーションコードのビルドタイプ、ビルドフレーバー、およびカスタムフィールドにアクセスできます。

シンプルなフレーバーでのアプローチ

  • ビルドタイプ：

    • debug
    • release

  • フレーバー：

    • dev
    • test
    • live

これにより、これらのビルドバリアントが生成されます（すべてを使用する必要はありません）。

  • devDebug
  • devRelease
  • testDebug
  • testRelease
  • liveDebug
  • liveRelease

ディメンションを使用して複数のフレーバーを組み合わせたアプローチ

  • フレーバーの寸法：

    • backend
    • target

  • ビルドタイプ：

    • debug
    • release

  • フレーバー：

    • target次元：
      • dev
      • test
      • live
    • backend次元：
      • production
      • test

これにより、これらのビルドバリアントが生成されます（ここでも、すべてを使用する必要はありません）。

  • productionDevDebug
  • productionDevRelease
  • productionTestDebug
  • productionTestRelease
  • productionLiveDebug
  • productionLiveRelease
  • testDevDebug
  • testDevRelease
  • testTestDebug
  • testTestRelease
  • testLiveDebug
  • testLiveRelease

ビルドフィールドの使用

ビルドタイプとビルドフレーバー宣言で追加の値を使用します。次に例を示します。

buildConfigField "boolean", "production_backend", "false"

または

buildConfigField "String", "backend", "\"production\""

16
Andrzej Zabost

build.gradle

_Android {

    buildTypes {
        debug {}
        qa {}
        release {}
    }

    flavorDimensions "client", "backend"
    productFlavors { 

//          First Product (FP)
        FP_dev {    
            dimension 'backend'
            buildConfigField("String", "TEST", "\"FP_dev\"")
        }
        FP_staging {
            dimension 'backend'
            buildConfigField("String", "TEST", "\"FP_staging\"")
        }
        FP_prod {
            dimension 'backend'
            buildConfigField("String", "TEST", "\"FP_prod\"")
        }
        firstproduct {
            dimension 'client'
            ...
        }


//          Second Product (SP)
        SP_dev {    
            dimension 'backend'
            buildConfigField("String", "TEST", "\"SP_dev\"")
        }
        SP_staging {
            dimension 'backend'
            buildConfigField("String", "TEST", "\"SP_staging\"")
        }
        SP_prod {
            dimension 'backend'
            buildConfigField("String", "TEST", "\"SP_prod\"")
        }
        secondproduct {
            dimension 'client'
            ...
        }
}

    variantFilter {
        variant ->
            def devDebug = "_devDebug"
            def stagingQA = "_stagingQa"
            def prodRelease = "_prodRelease"

            def firstproduct = "firstproductFP"
            def secondproduct = "secondproductFP"

            def needed = variant.name in [
                    firstproduct + devDebug,
                    firstproduct + stagingQA,
                    firstproduct + prodRelease,

                    secondproduct + devDebug,
                    secondproduct + stagingQA,
                    secondproduct + prodRelease
            ]
            variant.setIgnore(!needed)
    }

}
_

このソリューションのアプローチでは、複数の製品フレーバー用に複数のクライアントコンパイルとバックエンド環境を使用できます。

私がしたことは、バックエンドの開発環境をデバッグAndroidのコンパイルに関連付け、バックエンドのステージングをAndroid）のqaで、バックエンドの作成をAndroidのリリースに関連付けることでした。実稼働環境をデバッグしたり、開発環境を難読化したりする必要がある場合がありますが、このソリューションではそれが可能です。

  • firstproductFP_devDebug
  • firstproductFP_stagingQa
  • firstproductFP_prodRelease
  • secondproductSP_devDebug
  • secondproductSP_stagingQa
  • secondproductSP_prodRelease

コンパイル時の例firstproductFP_devDebug：

BuildConfig.Java

_public static final String FLAVOR = "firstproductFP_dev";
public static final String FLAVOR_client = "firstproduct";
public static final String FLAVOR_backend = "FP_dev";
public static final String BUILD_TYPE = "debug";
_

VariantFilter {}の範囲内では、buildConfigField()を使用してビルドタイプと製品フレーバーに基づいて値をコンパイルすることはできないことに注意してください。これにより、flavorDimensionsと大量のproductsFlavorsを使用する必要があります。また、アクティブなビルドバリアントの名前を変更することもできません。

重要：変数の値は、製品フレーバーの名前と一致する必要があります

GL

出典：

0
CORONEL Braian