このページは Cloud Translation API によって翻訳されました。

ビルドバリアントを設定する

このページでは、以下のビルドバリアントを設定する方法について説明します。 1 つのプロジェクトから複数のバージョンのアプリを作成する方法、依存関係と署名設定を適切に管理する必要があります。

各ビルドバリアントは、ビルド可能なさまざまなバージョンのアプリを表しています。たとえば、あるバージョンのアプリをビルドする限定されたコンテンツによる無料のものもう一つは含まれます。API レベルまたは他のデバイスのバリエーションに基づいて、異なるデバイスをターゲットとするアプリの異なるバージョンをビルドすることもできます。

ビルドバリアントは、Gradle で特定の構成、コード、リソースを集約するための一連のルールをビルドタイプとプロダクトフレーバーを提供します。ビルドバリアントは構成しなくてもビルドタイプとプロダクトフレーバーを形成するプロダクトフレーバーを設定します。

例: 「デモ」プロダクトフレーバー: 特定の機能を指定するカスタムソースコード、リソース、最小バージョンなどの制約を「デバッグ」build type は、異なるビルドを適用し、デバッグオプションや署名鍵などのパッケージ化設定を管理します。「この 2 つを組み合わせたビルドバリアントが「demoDebug」です。含まれている場合、「デモ」に含まれる構成とリソースの組み合わせです。プロダクトフレーバー、「debug」、ビルドタイプ、main/ ソースセットがあります。

ビルドタイプの設定

ビルドタイプは android 内で作成および設定できます。ブロック内の build.gradle.kts ブロックを使用します。リージョン Android Studio が自動的にデバッグビルドとリリースビルドを作成し、できます。デバッグビルドタイプはビルド構成に表示されませんが、 Android Studio は debuggable true を使用して設定します。これにより、安全な Android デバイス上でアプリをデバッグし、汎用デバッグキーストアを使用したアプリ署名を構成します。

特定の設定を追加または変更する場合、debug ビルドタイプを設定に追加することができます。次のサンプルでは、デバッグビルドタイプ用の applicationIdSuffix と設定「ステージング」debug ビルドタイプの設定を使用して初期化されるビルドタイプを指定します。

Kotlin

android {
    defaultConfig {
        manifestPlaceholders["hostName"] = "www.example.com"
        ...
    }
    buildTypes {
        getByName("release") {
            isMinifyEnabled = true
            proguardFiles(getDefaultProguardFile("proguard-android.txt"), "proguard-rules.pro")
        }

        getByName("debug") {
            applicationIdSuffix = ".debug"
            isDebuggable = true
        }

        /**
         * The `initWith` property lets you copy configurations from other build types,
         * then configure only the settings you want to change. This one copies the debug build
         * type, and then changes the manifest placeholder and application ID.
         */
        create("staging") {
            initWith(getByName("debug"))
            manifestPlaceholders["hostName"] = "internal.example.com"
            applicationIdSuffix = ".debugStaging"
        }
    }
}

Groovy

android {
    defaultConfig {
        manifestPlaceholders = [hostName:"www.example.com"]
        ...
    }
    buildTypes {
        release {
            minifyEnabled true
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        }

        debug {
            applicationIdSuffix ".debug"
            debuggable true
        }

        /**
         * The `initWith` property lets you copy configurations from other build types,
         * then configure only the settings you want to change. This one copies the debug build
         * type, and then changes the manifest placeholder and application ID.
         */
        staging {
            initWith debug
            manifestPlaceholders = [hostName:"internal.example.com"]
            applicationIdSuffix ".debugStaging"
        }
    }
}

注: ビルド構成ファイルに変更を加えると、Android Studio は新しい設定のプロジェクトを同期するよう要求します。プロジェクトを同期するには、[Sync Now] をクリックします。メッセージを変更またはクリックしたときに表示される プロジェクトの同期アイコンを表示します。Android Studio が設定のエラーを通知する場合は、問題の説明が記載された [Messages] ウィンドウが表示されます。

ビルドタイプで構成できるすべてのプロパティについて詳しくは、 <ph type="x-smartling-placeholder"></ph>を読んで BuildType リファレンス。

プロダクトフレーバーの設定

プロダクトフレーバーの作成は、ビルドタイプの作成に似ています。プロダクトフレーバーをビルド構成で productFlavors ブロックを指定し、必要な設定を含めます。プロダクトフレーバーは、 defaultConfig（defaultConfig のため）実際には <ph type="x-smartling-placeholder"></ph> ProductFlavor クラスを使用します。つまり、defaultConfig ブロックですべてのフレーバーの基本設定を提供でき、各フレーバーによって applicationId などのデフォルト値が変更される場合があります。宛先アプリケーション ID について詳しくは、アプリケーション ID を設定します。

注: main/ マニフェストファイルの package 属性を使用してパッケージ名を指定する必要もあります。また、kubectl の「get」コマンドやソースコード内のパッケージ名を使用して R クラスを参照したり、。これにより、 applicationId: 各プロダクトフレーバーに一意の ID をパッケージ化して配布できます。

すべてのフレーバーは、名前の付いたフレーバーディメンションに属していなければなりません。フレーバーディメンションとは、プロダクトフレーバーのグループです。すべてのフレーバーをフレーバーディメンションに割り当てる必要があります。そうしないと、次のビルドエラーが発生します。

  Error: All flavors must now belong to a named flavor dimension.
  The flavor 'flavor_name' is not assigned to a flavor dimension.

特定のモジュールがフレーバーディメンションを 1 つだけ指定すると、Android Gradle プラグインは自動的にモジュールのすべてのフレーバーをそのディメンションに割り当てます。

で確認できます。

次のサンプルコードでは、「version」という名前のフレーバーディメンションを作成し、「demo」と「full」というプロダクトフレーバーを追加しています。これらのフレーバーには、独自の <ph type="x-smartling-placeholder"></ph> applicationIdSuffix および versionNameSuffix:

Kotlin

android {
    ...
    defaultConfig {...}
    buildTypes {
        getByName("debug"){...}
        getByName("release"){...}
    }
    // Specifies one flavor dimension.
    flavorDimensions += "version"
    productFlavors {
        create("demo") {
            // Assigns this product flavor to the "version" flavor dimension.
            // If you are using only one dimension, this property is optional,
            // and the plugin automatically assigns all the module's flavors to
            // that dimension.
            dimension = "version"
            applicationIdSuffix = ".demo"
            versionNameSuffix = "-demo"
        }
        create("full") {
            dimension = "version"
            applicationIdSuffix = ".full"
            versionNameSuffix = "-full"
        }
    }
}

Groovy

android {
    ...
    defaultConfig {...}
    buildTypes {
        debug{...}
        release{...}
    }
    // Specifies one flavor dimension.
    flavorDimensions "version"
    productFlavors {
        demo {
            // Assigns this product flavor to the "version" flavor dimension.
            // If you are using only one dimension, this property is optional,
            // and the plugin automatically assigns all the module's flavors to
            // that dimension.
            dimension "version"
            applicationIdSuffix ".demo"
            versionNameSuffix "-demo"
        }
        full {
            dimension "version"
            applicationIdSuffix ".full"
            versionNameSuffix "-full"
        }
    }
}

注: 以前に作成したレガシーアプリがある場合は、 2021 年 8 月）に Google Play で APK を使用して配信する場合、複数の APK を使用してアプリを配信できるようになります。サポートしていない場合は、同じ applicationId 値を割り当てます。各バリエーションに異なる値を割り当てる versionCode。配布方法 Google Play でアプリのさまざまなバリエーションを個別のアプリとして扱う場合は、各バリエーションに異なる applicationId を割り当てる。

プロダクトフレーバーを作成して設定した後、通知バーで [Sync Now] をクリックします。同期が完了すると、Gradle はビルドタイプとプロダクトに基づいてビルドバリアントを自動的に作成さまざまなフレーバーがあり、 <product-flavor><Build-Type>。たとえば「demo」を作成しましたと「full」プロダクトフレーバーがあり、デフォルトの "debug"および「リリース」ビルドタイプに応じて、Gradle は次のビルドバリアントを作成します。

demoDebug
demoRelease
fullDebug
fullRelease

ビルドするビルドバリアントを選択し、 [Build] >[Select Build Variant] を選択して、ビルドバリアントを選択します。ビルドバリアントの独自の機能や特徴のカスタマイズを開始するには、使用する場合は、ソースの作成と管理を使用できます。

ビルドバリアント向けにアプリケーション ID を変更する

アプリの APK または AAB をビルドすると、ビルドツールによってアプリに build.gradle.kts の defaultConfig ブロックで定義されたアプリケーション ID 必要があります。ただし、複数の異なるバージョンのテーブルをを Google Play ストアで個別の掲載情報（「無料」など）として表示する「pro」は使用する場合は、個別のユーザーエージェントをビルドバリアント。それぞれが異なる指定します。

この場合、各ビルドバリアントをプロダクトフレーバー。productFlavors ブロック内のフレーバーごとに、applicationId プロパティを再定義するか、以下の例に示すように applicationIdSuffix を使用してデフォルトのアプリケーション ID の末尾にセグメントを付加することができます。

Kotlin

android {
    defaultConfig {
        applicationId = "com.example.myapp"
    }
    productFlavors {
        create("free") {
            applicationIdSuffix = ".free"
        }
        create("pro") {
            applicationIdSuffix = ".pro"
        }
    }
}

Groovy

android {
    defaultConfig {
        applicationId "com.example.myapp"
    }
    productFlavors {
        free {
            applicationIdSuffix ".free"
        }
        pro {
            applicationIdSuffix ".pro"
        }
    }
}

これにより、「free」プロダクトフレーバーのアプリケーション ID は「com.example.myapp.free」となります。

また、以下の例に示すように、applicationIdSuffix を使用し、ビルドタイプに基づいてセグメントを末尾に付加することもできます。

Kotlin

android {
    ...
    buildTypes {
        getByName("debug") {
            applicationIdSuffix = ".debug"
        }
    }
}

Groovy

android {
    ...
    buildTypes {
        debug {
            applicationIdSuffix ".debug"
        }
    }
}

Gradle はプロダクトフレーバーの後にビルドタイプ設定を適用するため、「フリーデバッグ」のアプリケーション IDビルドバリアントが "com.example.myapp.free.debug"2 つのアプリで同じアプリケーション ID を使用することはできないため、この方法はデバッグビルドとリリースビルドの両方を同じデバイスに組み込みたい場合に便利です。

以前のアプリ（8 月より前に作成されたもの）がある場合（2021 年）に、APK を使用して Google Play で配信され、同じアプリの掲載情報を使用して複数の APK を配布し、それぞれターゲットが異なるデバイス設定（API レベル、各ビルドバリアントに同じアプリケーション ID を使用する必要がありますが、別の versionCode を APK してください。詳しくは、複数 APK サポートをご覧ください。公開 1 つのアーティファクトを使用するため、AAB の使用は影響を受けません。バージョンコードとアプリケーション ID がデフォルトで使用されます。

ヒント: マニフェストファイルでアプリケーション ID を参照する必要がある場合は、任意のマニフェスト属性で ${applicationId} プレースホルダを使用できます。Gradle はビルド時にこのタグを実際のアプリケーション ID に置き換えます。詳細については、ビルドの挿入マニフェストに追加します。

複数のプロダクトフレーバーとフレーバーディメンションの組み合わせ

複数のプロダクトフレーバーの設定を組み合わせることが必要となる場合があります。たとえば、API レベルに応じて「full」と「demo」のプロダクトフレーバーで異なる設定を作成する必要がある場合などです。そのためには、 Android Gradle プラグインを使用すると、フレーバーとして複数のプロダクトフレーバーのグループを作成できます。定義できます。

アプリをビルドする際、Gradle は定義された各フレーバーディメンションに含まれるプロダクトフレーバー設定を組み合わせ、さらにビルドタイプ設定を使用して最終的なビルドバリアントを作成します。Gradle は同じフレーバーディメンションに属するプロダクトフレーバーを組み合わせる。

次のコードサンプルでは、 <ph type="x-smartling-placeholder"></ph> flavorDimensions プロパティを使用して「mode」を作成します。フレーバーグループ化して「フル」のおよび「demo」プロダクトフレーバーと「api」をフレーバーディメンションを使用して、API レベルに基づいてプロダクトフレーバー構成をグループ化します。

Kotlin

android {
  ...
  buildTypes {
    getByName("debug") {...}
    getByName("release") {...}
  }

  // Specifies the flavor dimensions you want to use. The order in which you
  // list the dimensions determines their priority, from highest to lowest,
  // when Gradle merges variant sources and configurations. You must assign
  // each product flavor you configure to one of the flavor dimensions.
  flavorDimensions += listOf("api", "mode")

  productFlavors {
    create("demo") {
      // Assigns this product flavor to the "mode" flavor dimension.
      dimension = "mode"
      ...
    }

    create("full") {
      dimension = "mode"
      ...
    }

    // Configurations in the "api" product flavors override those in "mode"
    // flavors and the defaultConfig block. Gradle determines the priority
    // between flavor dimensions based on the order in which they appear next
    // to the flavorDimensions property, with the first dimension having a higher
    // priority than the second, and so on.
    create("minApi24") {
      dimension = "api"
      minSdk = 24
      // To ensure the target device receives the version of the app with
      // the highest compatible API level, assign version codes in increasing
      // value with API level.
      versionCode = 30000 + (android.defaultConfig.versionCode ?: 0)
      versionNameSuffix = "-minApi24"
      ...
    }

    create("minApi23") {
      dimension = "api"
      minSdk = 23
      versionCode = 20000  + (android.defaultConfig.versionCode ?: 0)
      versionNameSuffix = "-minApi23"
      ...
    }

    create("minApi21") {
      dimension = "api"
      minSdk = 21
      versionCode = 10000  + (android.defaultConfig.versionCode ?: 0)
      versionNameSuffix = "-minApi21"
      ...
    }
  }
}
...

Groovy

android {
  ...
  buildTypes {
    debug {...}
    release {...}
  }

  // Specifies the flavor dimensions you want to use. The order in which you
  // list the dimensions determines their priority, from highest to lowest,
  // when Gradle merges variant sources and configurations. You must assign
  // each product flavor you configure to one of the flavor dimensions.
  flavorDimensions "api", "mode"

  productFlavors {
    demo {
      // Assigns this product flavor to the "mode" flavor dimension.
      dimension "mode"
      ...
    }

    full {
      dimension "mode"
      ...
    }

    // Configurations in the "api" product flavors override those in "mode"
    // flavors and the defaultConfig block. Gradle determines the priority
    // between flavor dimensions based on the order in which they appear next
    // to the flavorDimensions property, with the first dimension having a higher
    // priority than the second, and so on.
    minApi24 {
      dimension "api"
      minSdkVersion 24
      // To ensure the target device receives the version of the app with
      // the highest compatible API level, assign version codes in increasing
      // value with API level.

      versionCode 30000 + android.defaultConfig.versionCode
      versionNameSuffix "-minApi24"
      ...
    }

    minApi23 {
      dimension "api"
      minSdkVersion 23
      versionCode 20000  + android.defaultConfig.versionCode
      versionNameSuffix "-minApi23"
      ...
    }

    minApi21 {
      dimension "api"
      minSdkVersion 21
      versionCode 10000  + android.defaultConfig.versionCode
      versionNameSuffix "-minApi21"
      ...
    }
  }
}
...

Gradle で作成されるビルドバリアントの数は、各フレーバーディメンション内のフレーバーの数と、設定したビルドタイプをすべて乗算した数となります。Gradle が各ビルドバリアントまたは対応するアーティファクトに名前を付ける場合、優先度の高いフレーバーディメンションに属するフレーバーが最初に表示されます。その次にビルドタイプが続きます。

使用前のビルド構成と比較すると、Gradle は合計で 12 個の次の命名スキームのビルドバリアントを作成します。

ビルドバリアント: [minApi24, minApi23, minApi21][Demo, Full][Debug, Release]
対応する APK: app-[minApi24, minApi23, minApi21]-[demo, full]-[debug, release].apk

次に例を示します。

ビルドバリアント: minApi24DemoDebug

対応する APK: app-minApi24-demo-debug.apk

個別のプロダクトフレーバーおよびビルドバリアント用のソースセットディレクトリの作成に加え、プロダクトフレーバーの各組み合わせに対してもソースセットディレクトリを作成することが可能です。たとえば Java ソースを src/demoMinApi24/java/ ディレクトリに追加します。 Gradle はこれらのソースを、次の要素を組み合わせてバリアントを作成する場合にのみ、 2 つのプロダクトフレーバーがあります

プロダクトフレーバーの組み合わせに対して作成したソースセットは、個別の各プロダクトフレーバーに属するソースセットより優先されます。ソースセットと Gradle でどのようにリソースを統合する場合は、作成方法に関するセクションをお読みください。ソースセットをご覧ください。

バリアントのフィルタリング

Gradle は、設定されたプロダクトフレーバーとビルドタイプのすべての可能な組み合わせでビルドバリアントを作成します。ただし、不要なビルドバリアントや、コンテキストを定義します。特定のビルドバリアント構成を削除するには、モジュールレベルの build.gradle.kts でバリアントフィルタを作成する表示されます。

例として前のセクションのビルド構成を使用し、アプリのデモバージョンでは API レベル 23 以上のみをサポートすると仮定します。variantFilter ブロックを使用して、「minApi21」と「demo」のプロダクトフレーバーを組み合わせたすべてのビルドバリアント設定を除外できます。

Kotlin

android {
  ...
  buildTypes {...}

  flavorDimensions += listOf("api", "mode")
  productFlavors {
    create("demo") {...}
    create("full") {...}
    create("minApi24") {...}
    create("minApi23") {...}
    create("minApi21") {...}
  }
}

androidComponents {
    beforeVariants { variantBuilder ->
        // To check for a certain build type, use variantBuilder.buildType == "<buildType>"
        if (variantBuilder.productFlavors.containsAll(listOf("api" to "minApi21", "mode" to "demo"))) {
            // Gradle ignores any variants that satisfy the conditions above.
            variantBuilder.enable = false
        }
    }
}
...

Groovy

android {
  ...
  buildTypes {...}

  flavorDimensions "api", "mode"
  productFlavors {
    demo {...}
    full {...}
    minApi24 {...}
    minApi23 {...}
    minApi21 {...}
  }

  variantFilter { variant ->
      def names = variant.flavors*.name
      // To check for a certain build type, use variant.buildType.name == "<buildType>"
      if (names.contains("minApi21") && names.contains("demo")) {
          // Gradle ignores any variants that satisfy the conditions above.
          setIgnore(true)
      }
  }
}
...

ビルド設定にバリアントフィルタを追加して、[Sync] をクリック現在は、Gradle は次の条件を満たすビルドバリアントを無視します。自動的に適用されます。ビルドバリアントがメニューに表示されなくなる [ビルド >メニューバーから [Build Variant] を選択します。またはビルドバリアント ツールウィンドウバーをクリックします。

ソースセットの作成

Android Studio はデフォルトで、全ビルドバリアントで共有するすべての要素の main/ ソースセットとディレクトリを作成しますが、ただし、新しいソースセットを作成して、Gradle がコンパイルするファイルと特定のビルドタイプ、プロダクトフレーバー、さまざまな組み合わせに対応したパッケージをプロダクトフレーバー（フレーバーを使用する場合）ディメンションなど）、ビルドバリアントも参照できます。

たとえば、main/ ソースセットで基本的な機能を定義してプロダクトフレーバーのソースセットでクライアントごとにアプリのブランディングを変えることや、debug ビルドタイプを使用するビルドバリアント専用の特別なパーミッションやログ機能を含めることが可能です。

Gradle では、ソースセットのファイルとディレクトリが特定のフォルダで main/ ソースセットと同様に処理します。たとえば、Gradle の場合は「デバッグ」に固有の Kotlin または Java クラスファイルを想定している使用するビルドタイプを src/debug/kotlin/ ディレクトリまたは src/debug/java/ ディレクトリ。

Android Gradle プラグインには、ビルドタイプ、プロダクトごとにファイルを整理できますビルドバリアントに関するものです。たとえば、以下のタスク出力サンプルは、Gradle で「debug」ビルドタイプの特定のファイルがあると予想される場所を示しています。

------------------------------------------------------------
Project :app
------------------------------------------------------------

...

debug
----
Compile configuration: debugCompile
build.gradle name: android.sourceSets.debug
Java sources: [app/src/debug/java]
Kotlin sources: [app/src/debug/kotlin, app/src/debug/java]
Manifest file: app/src/debug/AndroidManifest.xml
Android resources: [app/src/debug/res]
Assets: [app/src/debug/assets]
AIDL sources: [app/src/debug/aidl]
RenderScript sources: [app/src/debug/rs]
JNI sources: [app/src/debug/jni]
JNI libraries: [app/src/debug/jniLibs]
Java-style resources: [app/src/debug/resources]

この出力を表示する手順は次のとおりです。

ツールウィンドウバーで [Gradle] をクリックします。
[MyApplication] >ToDo リスト >android および sourceSets をダブルクリックします。

[Tasks] フォルダを表示するには、Gradle でタスクリストを同期することもできます。方法は次のとおりです。
1. [ファイル] >設定 >試験運用版（Android Studio > [Settings] > [Experimental] など）。
2. [Do not（ Gradle 同期中に Gradle タスクリストを作成するをご覧ください。
Gradle がタスクを実行すると、[Run] ウィンドウが開き、出力です。

注: タスク出力には、アプリのテストを実行するために必要な test/ や androidTest/ といったテストソースセットなどのファイルのソースセットを管理する方法も示されています。

新しいビルドバリアントを作成する際に、Android Studio ではソースセットディレクトリは作成されませんが、便利なオプションがいくつか提供されます。たとえば、「debug」ビルドタイプ用の java/ ディレクトリを作成するには次の手順で操作します。

[Project] ペインを開き、 [Project] ビュー（ペイン上部のメニューから確認できます）
MyProject/app/src/ に移動します。
src ディレクトリを右クリックして、[ 新規 >ディレクトリ。
[Gradle Source Sets] の下のメニューから、[Gradle Source Sets] を選択します。 full/java。
Enter キーを押します。

Android Studio によってデバッグビルドタイプのソースセットディレクトリが作成され、次に、その中に java/ ディレクトリを作成します。または Android Studio は、新しいファイルをディレクトリに追加すると、ビルドバリアントごとにビルドする必要があります。

たとえば、「debug」の値の XML ファイルを作成するには、ビルドタイプ:

[Project] ペインで、src を右クリックします。 [新規] >XML > 値 XML ファイル。
XML ファイルの名前を入力するか、デフォルトの名前のままにします。
[Target Source Set] の横にあるメニューから、[ debug）。
[Finish] をクリックします。

「debug」ビルドタイプがターゲットソースセットとして指定されているため、Android Studio は XML ファイルを作成するときに必要となるディレクトリを自動的に作成します。結果のディレクトリ構造は次のようになります。図 1.

図 1. 「debug」の新しいソースセットディレクトリビルドあります。

アクティブなソースセットのアイコンには、アクティブであることを示す緑色のインジケーターが表示されます。「 debug ソースセットには、マージされることを示す [main] が末尾に付加されています main ソースセットに追加します。

同じ手順で、src/demo/ などプロダクトフレーバーのソースセットディレクトリや、src/demoDebug/ などビルドバリアントのソースセットディレクトリを作成できます。また、src/androidTestDemoDebug/ など特定のビルドバリアントを対象とするテストソースセットも作成できます。詳細については、テストソースセットをご覧ください。

デフォルトソースセットの設定を変更する

デフォルトのソースセットファイルに整理されていないソースがある場合構造を宣言する必要があります。ソースセットの作成では、 <ph type="x-smartling-placeholder"></ph> sourceSets ブロックで、Gradle が収集する場所を変更するソースセットの各コンポーネントのファイルを記述することもできます

sourceSets ブロックは、 android ブロック内で指定します。別のクラウドプロバイダをソースファイルGradle に指定する必要があるのは、モジュールレベルの build.gradle.kts ファイル。Gradle はソースセットコンポーネントごとにファイルを検索します。どのコンポーネントがそれらを複数のファイルやディレクトリにマッピングできるかどうか、 Android Gradle プラグイン API リファレンスをご覧ください。

次のコードサンプルは、app/other/ ディレクトリのソースをマッピングします。 main ソースセットの特定のコンポーネントに割り当てられ、 androidTest ソースセットのルートディレクトリ:

Kotlin

android {
  ...
  // Encapsulates configurations for the main source set.
  sourceSets.getByName("main") {
    // Changes the directory for Java sources. The default directory is
    // 'src/main/java'.
    java.setSrcDirs(listOf("other/java"))

    // If you list multiple directories, Gradle uses all of them to collect
    // sources. Because Gradle gives these directories equal priority, if
    // you define the same resource in more than one directory, you receive an
    // error when merging resources. The default directory is 'src/main/res'.
    res.setSrcDirs(listOf("other/res1", "other/res2"))

    // Note: Avoid specifying a directory that is a parent to one
    // or more other directories you specify. For example, avoid the following:
    // res.srcDirs = ['other/res1', 'other/res1/layouts', 'other/res1/strings']
    // Specify either only the root 'other/res1' directory or only the
    // nested 'other/res1/layouts' and 'other/res1/strings' directories.

    // For each source set, you can specify only one Android manifest.
    // By default, Android Studio creates a manifest for your main source
    // set in the src/main/ directory.
    manifest.srcFile("other/AndroidManifest.xml")
    ...
  }

  // Create additional blocks to configure other source sets.
  sourceSets.getByName("androidTest") {
      // If all the files for a source set are located under a single root
      // directory, you can specify that directory using the setRoot property.
      // When gathering sources for the source set, Gradle looks only in locations
      // relative to the root directory you specify. For example, after applying the
      // configuration below for the androidTest source set, Gradle looks for Java
      // sources only in the src/tests/java/ directory.
      setRoot("src/tests")
      ...
  }
}
...

Groovy

android {
  ...
  sourceSets {
    // Encapsulates configurations for the main source set.
    main {
      // Changes the directory for Java sources. The default directory is
      // 'src/main/java'.
      java.srcDirs = ['other/java']

      // If you list multiple directories, Gradle uses all of them to collect
      // sources. Because Gradle gives these directories equal priority, if
      // you define the same resource in more than one directory, you receive an
      // error when merging resources. The default directory is 'src/main/res'.
      res.srcDirs = ['other/res1', 'other/res2']

      // Note: Avoid specifying a directory that is a parent to one
      // or more other directories you specify. For example, avoid the following:
      // res.srcDirs = ['other/res1', 'other/res1/layouts', 'other/res1/strings']
      // Specify either only the root 'other/res1' directory or only the
      // nested 'other/res1/layouts' and 'other/res1/strings' directories.

      // For each source set, you can specify only one Android manifest.
      // By default, Android Studio creates a manifest for your main source
      // set in the src/main/ directory.
      manifest.srcFile 'other/AndroidManifest.xml'
      ...
    }

    // Create additional blocks to configure other source sets.
    androidTest {

      // If all the files for a source set are located under a single root
      // directory, you can specify that directory using the setRoot property.
      // When gathering sources for the source set, Gradle looks only in locations
      // relative to the root directory you specify. For example, after applying the
      // configuration below for the androidTest source set, Gradle looks for Java
      // sources only in the src/tests/java/ directory.
      setRoot 'src/tests'
      ...
    }
  }
}
...

1 つのソースディレクトリは 1 つのソースセットにのみ属すことができます。たとえば、 test ソースセットと androidTest ソースセットで同じテストソースを使用します。このこれは、Android Studio でソースセットごとに個別の IntelliJ モジュールが作成されるため、重複コンテンツルートが存在する場合があります。

ソースセットでビルドする

ソースセットディレクトリには、特定の設定でのみパッケージ化するコードやリソースを入れておくことができます。たとえば「demoDebug」をビルドするビルドバリアントは、モデルの「demo」プロダクトフレーバーと「デバッグ」ビルドタイプに基づいて、Gradle は次の優先順位を付けます。

src/demoDebug/（ビルドバリアントソースセット）
src/debug/（ビルドタイプのソースセット）
src/demo/（プロダクトフレーバーのソースセット）
src/main/（メインのソースセット）

プロダクトフレーバーの組み合わせに対して作成されたソースセットには、すべてのフレーバーディメンションを含める必要があります。たとえば、ビルドバリアントのソースセットは、ビルドタイプとオールフレーバーの組み合わせにする必要があります。定義できます。すべてではないものの複数をカバーするフォルダに関連するコードとリソースのマージフレーバーディメンションはサポートされていません。

複数のプロダクトを組み合わせた場合プロダクトフレーバーのプロダクトフレーバーの優先度はフレーバーによって決まります。グループ化しますラベルでフレーバーのディメンションをリストする場合、 <ph type="x-smartling-placeholder"></ph> android.flavorDimensions プロパティと、そのプロダクトフレーバーがリストにある最初のフレーバーディメンションに属し、というように 2 つ目のフレーバーディメンションに属するものが抽出されます。またプロダクトフレーバーの組み合わせに対して作成したソースセットは、各プロダクトフレーバーに属するソースセットよりも優先度が高くなります。

優先順位によって、どのソースセットが優先されることもありません。demoDebug/ ソースセットディレクトリにはそのビルドバリアント固有のファイルが含まれる可能性が高いため、debug/ で定義されているファイルが demoDebug/ に含まれている場合、Gradle は demoDebug/ ソースセットのファイルを使用します。Gradle では同様に、ビルドタイプとプロダクトフレーバーのソースセットのファイルに対して main/ にある同じファイルよりも高い優先度を付与します。Gradle では、以下のビルドルールを適用するときに、この優先順位が考慮されます。

kotlin/ ディレクトリまたは java/ ディレクトリ内のすべてのソースコードがコンパイルされる単一の出力を生成します。
注: 特定のビルドバリアントについて、Gradle はビルドをスローします。 2 つ以上のソースセットディレクトリが定義されている場合に、呼び出すことができます。たとえば、デバッグアプリをビルドする場合、 src/debug/Utility.kt と src/main/Utility.kt。Gradle は両方を参照するため、依存関係があり、「重複クラス」がスローされるエラーが発生します。別のバージョンの Utility.kt を異なるビルドタイプを使用する場合は、各ビルドタイプで独自のバージョンの main/ ソースセットに含めないでください。
複数のマニフェストは単一のマニフェストにマージされ、優先度が高い順序は前の例のリストと同じです。つまり、ビルドタイプのマニフェスト設定により、プロダクトフレーバーなどのマニフェスト設定がオーバーライドされます。詳しくは、マニフェストのマージをご覧ください。
values/ ディレクトリ内のファイルが統合されます説明します。2 つのファイルの名前が同じ場合（2 つのファイルなど） strings.xml ファイルの場合、優先度は示しています。つまり、ビルドタイプのソースセットのファイルで定義されている値により、プロダクトフレーバーなどの同じファイルで定義されている値がオーバーライドされます。
res/ と asset/ ディレクトリのリソースは一緒にパッケージ化されます。同じ名前を持つリソースが Namespace にソースセットが 2 つ以上ある場合、リストと同じ順序で優先度が与えられます。説明しました。
Gradle がライブラリに含まれるリソースとマニフェストを提供する依存関係がアプリをビルドするときに最も低い優先度になります。

依存関係の宣言

特定のビルドバリアントの依存関係を設定するにはテストソースセットビルドバリアントまたはテストソースセットの名前を Implementation キーワードを使用します。

Kotlin

dependencies {
    // Adds the local "mylibrary" module as a dependency to the "free" flavor.
    "freeImplementation"(project(":mylibrary"))

    // Adds a remote binary dependency only for local tests.
    testImplementation("junit:junit:4.12")

    // Adds a remote binary dependency only for the instrumented test APK.
    androidTestImplementation("com.android.support.test.espresso:espresso-core:3.5.1")
}

Groovy

dependencies {
    // Adds the local "mylibrary" module as a dependency to the "free" flavor.
    freeImplementation project(":mylibrary")

    // Adds a remote binary dependency only for local tests.
    testImplementation 'junit:junit:4.12'

    // Adds a remote binary dependency only for the instrumented test APK.
    androidTestImplementation 'com.android.support.test.espresso:espresso-core:3.5.1'
}

依存関係の構成について詳しくはビルド依存関係を追加するをご覧ください。

バリアント認識型の依存関係管理を使用する

Android Gradle プラグイン 3.0.0 以降には、新しい依存関係メカニズムが組み込まれており、は、ライブラリを使用するときにバリアントを照合します。アプリの debug バリアントを意味しますは、ライブラリの debug バリアントを自動的に使用します。また、kubectl のフレーバー: アプリの freeDebug バリアントがライブラリの freeDebug を使用するあります。

プラグインでバリエーションを正確にマッチングさせるには、以下を行う必要があります。一致する代替手段を用意する（説明のとおり）直接一致が不可能な場合は次のセクションで説明します。

たとえば、アプリで「staging」というビルドタイプを設定しているにもかかわらず、依存関係が維持されません。プラグインでアプリの「staging」バージョンをビルドしようとしたときに、どのバージョンのライブラリを使用すべきかを判断できません。そのため、次のようなエラーメッセージが表示されます。

Error:Failed to resolve: Could not resolve project :mylibrary.
Required by:
    project :app

バリアントのマッチングに関連するビルドエラーの解決

このプラグインには DSL 要素が含まれており、Gradle が以下の状況を解決する方法を制御できます。アプリと依存関係の間で直接的なバリアントマッチングを行うことはできません。

バリアント認識型の依存関係マッチングに関連する問題と、 DSL プロパティを使用して解決します。

依存関係にないビルドタイプがアプリに含まれている。

たとえば、お客様のアプリには「ステージング」という言葉が含まれていますビルドタイプがありますが、依存関係にはビルドタイプのみ "debug"および「release」ビルドタイプ。

なお、ライブラリの依存関係にビルドが含まれている場合でも、問題はありません。おすすめしますこれは、プラグインがビルドタイプをリクエストします。

matchingFallbacks を使用して、特定のビルドタイプの代わりにマッチングするビルドタイプを指定します。使用します。

Kotlin

// In the app's build.gradle.kts file.
android {
    buildTypes {
        getByName("debug") {}
        getByName("release") {}
        create("staging") {
            // Specifies a sorted list of fallback build types that the
            // plugin can try to use when a dependency does not include a
            // "staging" build type. You may specify as many fallbacks as you
            // like, and the plugin selects the first build type that's
            // available in the dependency.
            matchingFallbacks += listOf("debug", "qa", "release")
        }
    }
}

Groovy

// In the app's build.gradle file.
android {
    buildTypes {
        debug {}
        release {}
        staging {
            // Specifies a sorted list of fallback build types that the
            // plugin can try to use when a dependency does not include a
            // "staging" build type. You may specify as many fallbacks as you
            // like, and the plugin selects the first build type that's
            // available in the dependency.
            matchingFallbacks = ['debug', 'qa', 'release']
        }
    }
}

アプリとライブラリの両方に存在する特定のフレーバーディメンションライブラリに含まれていないフレーバーがアプリに含まれています。

たとえば、アプリとそのライブラリ依存関係の両方に「tier」フレーバーディメンションが存在するが、一方、「階層」では、アプリのディメンションに「無料」が含まれていると「有料」ありますが、「demo」のみを含む依存関係と「有料」同じディメンションの複数のフレーバーがあります。

アプリとそのライブラリの両方に存在する特定のフレーバーディメンションの場合、含まれている場合、アプリのプロダクトフレーバーがライブラリに含まれている場合でも、できません。これは、プラグインが依存関係からはフレーバーをリクエストしていないためです。

matchingFallbacks を使用して、アプリの「free」にマッチする別の候補を指定するプロダクトフレーバーは以下のようになります。

Kotlin

// In the app's build.gradle.kts file.
android {
    defaultConfig{
    // Don't configure matchingFallbacks in the defaultConfig block.
    // Instead, specify fallbacks for a given product flavor in the
    // productFlavors block, as shown below.
  }
    flavorDimensions += "tier"
    productFlavors {
        create("paid") {
            dimension = "tier"
            // Because the dependency already includes a "paid" flavor in its
            // "tier" dimension, you don't need to provide a list of fallbacks
            // for the "paid" flavor.
        }
        create("free") {
            dimension = "tier"
            // Specifies a sorted list of fallback flavors that the plugin
            // can try to use when a dependency's matching dimension does
            // not include a "free" flavor. Specify as many
            // fallbacks as you like; the plugin selects the first flavor
            // that's available in the dependency's "tier" dimension.
            matchingFallbacks += listOf("demo", "trial")
        }
    }
}

Groovy

// In the app's build.gradle file.
android {
    defaultConfig{
    // Don't configure matchingFallbacks in the defaultConfig block.
    // Instead, specify fallbacks for a given product flavor in the
    // productFlavors block, as shown below.
  }
    flavorDimensions 'tier'
    productFlavors {
        paid {
            dimension 'tier'
            // Because the dependency already includes a "paid" flavor in its
            // "tier" dimension, you don't need to provide a list of fallbacks
            // for the "paid" flavor.
        }
        free {
            dimension 'tier'
            // Specifies a sorted list of fallback flavors that the plugin
            // can try to use when a dependency's matching dimension does
            // not include a "free" flavor. Specify as many
            // fallbacks as you like; the plugin selects the first flavor
            // that's available in the dependency's "tier" dimension.
            matchingFallbacks = ['demo', 'trial']
        }
    }
}

アプリに含まれていないフレーバーディメンションがライブラリ依存関係に含まれている。

たとえば、ライブラリ依存関係には「minApi」ディメンション用のフレーバーが含まれているが、アプリには「tier」ディメンション用のフレーバーしか含まれていない場合などです。"freeDebug" ビルドをビルドし、使用していない場合、プラグインは「minApi23Debug」コードを使用するかどうかをまたは「minApi18Debug」依存関係のバージョンを指定します。

なお、ライブラリに含まれているフレーバーディメンションがアプリに含まれている場合でも、問題はありません。含まれません。プラグインでは、ライブラリ依存関係に存在するディメンションのみのフレーバーをマッチングするためです。たとえば、依存関係に ABI のディメンションが含まれていない場合、「freeX86Debug」という「freeDebug」というコードライブラリをバージョン確認します。

defaultConfig ブロックで missingDimensionStrategy を使用して、プラグインのデフォルトのフレーバーで、存在しない各ディメンションから選択できます。下の図をご覧ください。使用します。また、productFlavors ブロック内で選択肢をオーバーライドして、存在しないディメンションに対してフレーバーごとに異なるマッチング方針を指定することもできます。

Kotlin

// In the app's build.gradle.kts file.
android {
    defaultConfig{
    // Specifies a sorted list of flavors that the plugin can try to use from
    // a given dimension. This tells the plugin to select the "minApi18" flavor
    // when encountering a dependency that includes a "minApi" dimension.
    // You can include additional flavor names to provide a
    // sorted list of fallbacks for the dimension.
    missingDimensionStrategy("minApi", "minApi18", "minApi23")
    // Specify a missingDimensionStrategy property for each
    // dimension that exists in a local dependency but not in your app.
    missingDimensionStrategy("abi", "x86", "arm64")
    }
    flavorDimensions += "tier"
    productFlavors {
        create("free") {
            dimension = "tier"
            // You can override the default selection at the product flavor
            // level by configuring another missingDimensionStrategy property
            // for the "minApi" dimension.
            missingDimensionStrategy("minApi", "minApi23", "minApi18")
        }
        create("paid") {}
    }
}

Groovy

// In the app's build.gradle file.
android {
    defaultConfig{
    // Specifies a sorted list of flavors that the plugin can try to use from
    // a given dimension. This tells the plugin to select the "minApi18" flavor
    // when encountering a dependency that includes a "minApi" dimension.
    // You can include additional flavor names to provide a
    // sorted list of fallbacks for the dimension.
    missingDimensionStrategy 'minApi', 'minApi18', 'minApi23'
    // Specify a missingDimensionStrategy property for each
    // dimension that exists in a local dependency but not in your app.
    missingDimensionStrategy 'abi', 'x86', 'arm64'
    }
    flavorDimensions 'tier'
    productFlavors {
        free {
            dimension 'tier'
            // You can override the default selection at the product flavor
            // level by configuring another missingDimensionStrategy property
            // for the 'minApi' dimension.
            missingDimensionStrategy 'minApi', 'minApi23', 'minApi18'
        }
        paid {}
    }
}

詳細については、matchingFallbacks をご覧ください。および missingDimensionStrategy Android Gradle プラグイン DSL リファレンスにあります。

署名設定の設定

Gradle は、明示的に定義しない限り、リリースビルドの APK または AAB に署名しません。署名設定を指定します。署名鍵がない場合は、アップロード鍵とキーストアを生成する使用できます。

Gradle ビルド設定を使用して release ビルドタイプの署名設定を手動で設定するには、次の手順を行います。

キーストアを作成します。キーストアはバイナリファイルであり、秘密鍵が格納されています。キーストアは安全な場所に保管する必要があります。
秘密鍵を作成します。秘密鍵はアプリの署名に使用されます。アプリに追加されたり、不正な第三者に開示されたりすることはありません。

署名設定をモジュールレベルの build.gradle.kts ファイルに追加します。

Kotlin

...
android {
    ...
    defaultConfig {...}
    signingConfigs {
        create("release") {
            storeFile = file("myreleasekey.keystore")
            storePassword = "password"
            keyAlias = "MyReleaseKey"
            keyPassword = "password"
        }
    }
    buildTypes {
        getByName("release") {
            ...
            signingConfig = signingConfigs.getByName("release")
        }
    }
}

Groovy

...
android {
    ...
    defaultConfig {...}
    signingConfigs {
        release {
            storeFile file("myreleasekey.keystore")
            storePassword "password"
            keyAlias "MyReleaseKey"
            keyPassword "password"
        }
    }
    buildTypes {
        release {
            ...
            signingConfig signingConfigs.release
        }
    }
}

注: リリースキーとキーストアのパスワードをビルドファイルに含めることは、セキュリティ上の理由からおすすめできません。代わりに、これらのパスワードを取得するようにビルドファイルを設定します。環境変数から値を取得するか、ビルドプロセスでできます。

パスワードを環境変数から取得する方法:

Kotlin

storePassword = System.getenv("KSTOREPWD")
keyPassword = System.getenv("KEYPWD")

Groovy

storePassword System.getenv("KSTOREPWD")
keyPassword System.getenv("KEYPWD")

または、ローカルのプロパティファイルからキーストアを読み込むこともできます。セキュリティ上の理由から、ソース管理に追加します。代わりに、サービスごとにローカルで開発者です。詳しくは、<ph type="x-smartling-placeholder"></ph>をご覧くださいビルドファイルから署名情報を削除する。

このプロセスが完了すれば、アプリを配布したり、Google Play で公開したりできます。

警告: キーストアと秘密鍵は安全な場所に保管し、セキュアバックアップを取るようにしてください。Play アプリ署名を使用していて、アップロード鍵を紛失した場合は、Play Console からリセットをリクエストできます。 Play アプリ署名を使用せずにアプリを公開する場合（2021 年 8 月より前に作成したアプリの場合）、アプリ署名鍵を紛失すると、それ以降アプリを更新できなくなります。アプリのすべてのバージョンに同じ署名鍵で署名する必要があるためです。

Wear OS アプリの署名

Wear OS アプリを公開する際は、スマートウォッチの APK とスマートフォンの APK（省略可）の両方をあります。Wear OS アプリのパッケージ化と署名について詳しくは、Wear アプリのパッケージ化と配布をご覧ください。

ビルド バリアントを設定する

ビルドタイプの設定

Kotlin

Groovy

プロダクト フレーバーの設定

Kotlin

Groovy

ビルド バリアント向けにアプリケーション ID を変更する

Kotlin

Groovy

Kotlin

Groovy

複数のプロダクト フレーバーとフレーバー ディメンションの組み合わせ

Kotlin

Groovy

バリアントのフィルタリング

Kotlin

Groovy

ソースセットの作成

デフォルト ソースセットの設定を変更する

Kotlin

Groovy

ソースセットでビルドする

依存関係の宣言

Kotlin

Groovy

バリアント認識型の依存関係管理を使用する

バリアントのマッチングに関連するビルドエラーの解決

Kotlin

Groovy

Kotlin

Groovy

Kotlin

Groovy

署名設定の設定

Kotlin

Groovy

Kotlin

Groovy

Wear OS アプリの署名

ビルドバリアントを設定する

プロダクトフレーバーの設定

ビルドバリアント向けにアプリケーション ID を変更する

複数のプロダクトフレーバーとフレーバーディメンションの組み合わせ

デフォルトソースセットの設定を変更する