このドキュメントはビルドの設定の概要を基に構成されており、ビルド バリアントを設定して単一のプロジェクトからさまざまなバージョンのアプリを作成する方法と、依存関係と署名設定を適切に管理する方法について説明しています。
各ビルド バリアントは、ビルド可能なさまざまなバージョンのアプリを表しています。たとえば、コンテンツが制限された無料版のアプリと、多くのコンテンツが含まれた有料版のアプリを作成することができます。API レベルまたは他のデバイスのバリエーションに基づいて、異なるデバイスをターゲットとするアプリの異なるバージョンをビルドすることもできます。ただし、デバイスの ABI または画面密度に基づいて異なるバージョンをビルドする場合は、複数の APK をビルドします。
Gradle で特定のルールセットを使用して、ビルドタイプとプロダクト フレーバー内に構成されている設定、コード、リソースを組み合わせた結果がビルド バリアントです。ビルド バリアントは直接設定するものではなく、ビルド バリアントを構成するビルドタイプとプロダクト フレーバーを設定します。
たとえば、「demo」プロダクト フレーバーではカスタム ソースコード、リソース、最小 API レベルなど、さまざまな機能とデバイス要件を指定することができます。また、「debug」ビルドタイプでは、デバッグ オプションや署名鍵など、さまざまなビルドとパッケージの設定を適用します。その結果、ビルド バリアントはアプリの「demoDebug」バージョンになります。このバージョンには、「demo」プロダクト フレーバー、「debug」ビルドタイプ、main/
ソースセットに含まれている設定とリソースの組み合わせが含まれます。
ビルドタイプの設定
モジュールレベルの build.gradle
ファイルの android
ブロック内で、ビルドタイプを作成して設定できます。新しいモジュールを作成するときは、Android Studio が debug および release ビルドタイプを自動的に作成します。debug ビルドタイプはビルド構成ファイルに表示されませんが、Android Studio では debuggable true
で debug ビルドタイプが設定されます。これにより、安全な Android デバイスでアプリをデバッグし、汎用デバッグ キーストアでアプリ署名を設定できるようになります。
特定の設定を追加または変更する場合、debug ビルドタイプを設定に追加することができます。次のサンプルでは、debug ビルドタイプ向けに applicationIdSuffix
を指定し、debug ビルドタイプの設定を使用して初期化される「staging」ビルドタイプを設定しています。
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 allows you to 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" } } }
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 allows you to 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" } } }
注: ビルド構成ファイルに変更を加えると、Android Studio は新しい設定のプロジェクトを同期するよう要求します。プロジェクトを同期するには、変更を加えた直後に表示される通知バーの [Sync Now] をクリックするか、ツールバーの [Sync Project] をクリックします。Android Studio が設定のエラーを通知する場合は、問題の説明が記載された [Messages] ウィンドウが表示されます。
ビルドタイプで設定できるすべてのプロパティについて詳しくは、ビルドタイプの DSL リファレンスをご覧ください。
プロダクト フレーバーの設定
プロダクト フレーバーの作成方法はビルドタイプと同じで、ビルド構成の productFlavors
ブロックにプロダクト フレーバーを追加して必要な設定を含めます。defaultConfig
が実際には ProductFlavor
クラスに属しているため、プロダクト フレーバーでは defaultConfig
と同じプロパティがサポートされます。つまり、defaultConfig
ブロックですべてのフレーバーの基本設定を提供でき、各フレーバーによって applicationId
などのデフォルト値が変更される場合があります。アプリケーション ID について詳しくは、アプリケーション ID の設定をご覧ください。
注: main/
マニフェスト ファイルの package
属性を使用してパッケージ名を指定する必要もあります。また、ソースコードでそのパッケージ名を使用して R クラスを参照したり、関連するアクティビティやサービスの登録を解決したりする必要があります。これにより、ソースコードを変更せずに applicationId
を使用してパッケージ化および配布用の一意の ID を各プロダクト フレーバーに提供できるようになります。
すべてのフレーバーは、名前の付いたフレーバー ディメンションに属していなければなりません。フレーバー ディメンションとは、プロダクト フレーバーのグループです。すべてのフレーバーをフレーバー ディメンションに割り当てる必要があります。割り当てない場合、次のようなビルドエラーが発生します。特定のモジュールで 1 つのフレーバー ディメンションのみが指定されている場合、Android Gradle プラグインはモジュールのすべてのフレーバーをそのディメンションに自動的に割り当てます。
Error:All flavors must now belong to a named flavor dimension. The flavor 'flavor_name' is not assigned to a flavor dimension.
次のサンプルコードでは、「version」という名前のフレーバー ディメンションを作成し、「demo」と「full」というプロダクト フレーバーを追加しています。これらのフレーバーでは、applicationIdSuffix
と versionNameSuffix
という独自のフレーバーを提供しています。
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" } } }
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" } } }
注: Google Play で APK を使用して配信している旧式アプリ(2021 年 8 月より前に作成)の場合、Google Play でマルチ APK サポートを使用してアプリを配信するには、すべてのバリアントに同じ applicationId
値を割り当てて、バリアントごとに異なる versionCode
を付与します。Google Play でさまざまなバリアントのアプリを個別のアプリとして配布するには、各バリアントに異なる applicationId
を割り当てる必要があります。
プロダクト フレーバーを作成して設定した後、通知バーで [Sync Now] をクリックします。同期が完了すると、Gradle はビルドタイプとプロダクト フレーバーに基づいてビルド バリアントを自動的に作成し、<product-flavor><Build-Type>
の名前を付けます。たとえば、「demo」と「full」のプロダクト フレーバーを作成し、ビルドタイプをデフォルトの「debug」と「release」のままにした場合、Gradle は次のビルド バリアントを作成します。
- demoDebug
- demoRelease
- fullDebug
- fullRelease
ビルドして実行するビルド バリアントを、この中のいずれかに変更できます。変更するには、[Build] > [Select Build Variant] に移動し、プルダウン メニューからビルド バリアントを選択します。独自の機能とリソースで各ビルド バリアントをカスタマイズするには、ソースセットを作成および管理する方法を把握しておく必要があります。
複数のプロダクト フレーバーとフレーバー ディメンションの組み合わせ
複数のプロダクト フレーバーの設定を組み合わせることが必要となる場合があります。たとえば、API レベルに応じて「full」と「demo」のプロダクト フレーバーで異なる設定を作成する必要がある場合などです。これを行うには、Android Plugin for Gradle を使用して、複数のプロダクト フレーバーをフレーバー ディメンションとしてグループ化します。アプリをビルドする際、Gradle は定義された各フレーバー ディメンションに含まれるプロダクト フレーバー設定を組み合わせ、さらにビルドタイプ設定を使用して最終的なビルド バリアントを作成します。Gradle では、同じフレーバー ディメンションに属するプロダクト フレーバーが組み合わされることはありません。
下記のコードサンプルでは、flavorDimensions
プロパティを使用して「mode」フレーバー ディメンションを作成し、「full」プロダクト フレーバーと「demo」プロダクト フレーバーをグループ化しています。さらに、「api」フレーバー ディメンションを作成し、API レベルに基づいてプロダクト フレーバー設定をグループ化しています。
Groovy
android { ... buildTypes { debug {...} release {...} } // Specifies the flavor dimensions you want to use. The order in which you // list each dimension determines its 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 above--the first dimension has 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. To learn more about assigning version codes to // support app updates and uploading to Google Play, read Multiple APK Support 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" ... } } } ...
Kotlin
android { ... buildTypes { getByName("debug") {...} getByName("release") {...} } // Specifies the flavor dimensions you want to use. The order in which you // list each dimension determines its 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 { 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 above--the first dimension has a higher // priority than the second, and so on. create("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. To learn more about assigning version codes to // support app updates and uploading to Google Play, read Multiple APK Support versionCode = 30000 + android.defaultConfig.versionCode versionNameSuffix = "-minApi24" ... } create("minApi23") { dimension = "api" minSdkVersion(23) versionCode = 20000 + android.defaultConfig.versionCode versionNameSuffix = "-minApi23" ... } create("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
ファイル内にバリアント フィルタを作成します。
例として前のセクションのビルド構成を使用し、アプリのデモバージョンでは API レベル 23 以上のみをサポートすると仮定します。variantFilter
ブロックを使用して、「minApi21」と「demo」のプロダクト フレーバーを組み合わせたすべてのビルド バリアント設定を除外できます。
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) } } } ...
Kotlin
android { ... buildTypes {...} flavorDimensions "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.enabled = false } } } ...
ビルド構成にバリアント フィルタを追加して通知バーで [Sync Now] をクリックすると、Gradle は指定された条件に一致するすべてのビルド バリアントを無視します。そのため、メニューバーの [Build] > [Select Build Variant](またはツール ウィンドウ バーの [Build Variants] )をクリックしたときに、プルダウン メニューにこれらのビルド バリアントが表示されなくなります。
ソースセットの作成
Android Studio はデフォルトで、全ビルド バリアントで共有するすべての要素の main/
ソースセットとディレクトリを作成しますが、新しいソースセットを作成して特定のビルドタイプ、プロダクト フレーバー(およびフレーバー ディメンションを使用している場合はプロダクト フレーバーの組み合わせ)、ビルド バリアントごとに Gradle でコンパイルおよびパッケージ化するファイルを厳密に管理することもできます。たとえば、main/
ソースセットで基本的な機能を定義してプロダクト フレーバーのソースセットでクライアントごとにアプリのブランディングを変えたり、debug ビルドタイプを使用するビルド バリアント専用の特別なパーミッションやログ機能を含めたりすることが可能です。
Gradle では、main/
ソースセットの場合と同じように特定の方法でソースセット ファイルとディレクトリを管理する必要があります。たとえば、「debug」ビルドタイプ固有の Java クラスファイルは src/debug/java/
ディレクトリに配置しなければなりません。
Android Plugin for Gradle では、各ビルドタイプ、プロダクト フレーバー、ビルド バリアントに応じたファイル構成を表示する便利な Gradle 機能が提供されています。たとえば、以下のタスク出力サンプルは、Gradle で「debug」ビルドタイプの特定のファイルがあると予想される場所を示しています。
------------------------------------------------------------ Project :app ------------------------------------------------------------ ... debug ---- Compile configuration: compile build.gradle name: android.sourceSets.debug Java sources: [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]
この出力を表示する手順は次のとおりです。
- IDE ウィンドウの右側にある [Gradle]
をクリックします。
- [MyApplication] > [Tasks] > [android] に移動して [sourceSets] をダブルクリックします。Gradle がタスクを実行すると、[Run] ウィンドウが開いて出力が表示されます。
- 上記のようにテキストモードで表示されない場合は、[Run] ウィンドウの左側にある [Toggle view]
をクリックします。
注: タスク出力には、アプリのテストを実行するために必要な test/
や androidTest/
といったテスト ソースセットなどのファイルのソースセットを管理する方法も示されています。
新しいビルド バリアントを作成する際に、Android Studio ではソースセット ディレクトリは作成されませんが、便利なオプションがいくつか提供されます。たとえば、「debug」ビルドタイプ用の java/
ディレクトリを作成するには次の手順で操作します。
- [Project] ペインを開き、ペインの上部にあるプルダウン メニューから [Project] ビューを選択します。
MyProject/app/src/
に移動します。src
ディレクトリを右クリックし、[New] > [Folder] > [Java Folder] を選択します。- [Target Source Set] の横にあるプルダウン メニューから [debug] を選択します。
- [Finish] をクリックします。
Android Studio は debug ビルドタイプのソースセット ディレクトリを作成し、そのディレクトリ内に java/
ディレクトリを作成します。または、特定のビルド バリアント用の新しいファイルをプロジェクトに追加する際に、Android Studio がディレクトリを作成するようにすることもできます。たとえば、「debug」ビルドタイプの values.xml ファイルは次の手順で作成します。
- 同じ [Project] ペインで
src
ディレクトリを右クリックし、[New] > [XML] > [Values XML File] を選択します。 - XML ファイルの名前を入力するか、デフォルトの名前のままにします。
- [Target Source Set] の横にあるプルダウン メニューから [debug] を選択します。
- [Finish] をクリックします。
「debug」ビルドタイプがターゲット ソースセットとして指定されているため、Android Studio は XML ファイルを作成するときに必要となるディレクトリを自動的に作成します。この結果、図 2 のようなディレクトリ構造ができあがります。

図 2. debug ビルドタイプの新しいソースセット ディレクトリ。
同じ手順で、src/demo/
などプロダクト フレーバーのソースセット ディレクトリや、src/demoDebug/
などビルド バリアントのソースセット ディレクトリを作成できます。また、src/androidTestDemoDebug/
など特定のビルド バリアントを対象とするテスト ソースセットも作成できます。詳細については、テスト ソースセットをご覧ください。
デフォルトのソースセットの構成を変更する
ソースセットの作成セクションでは Gradle で想定するデフォルトのソースセット ファイル構成について説明しましたが、ソースファイルがこの構成になってない場合は、sourceSets
ブロックを使用すると、Gradle がソースセットの各コンポーネントのファイルを収集する際に参照する場所を変更できます。ファイルの場所を変更する必要はなく、モジュール レベルの build.gradle
ファイルからの相対パスを指定するだけです。Gradle はここで各ソースセット コンポーネントのファイルを見つけることができます。設定可能なコンポーネントや、それらを複数のファイルおよびディレクトリにマッピングできるどうかについては、Android Gradle プラグイン API リファレンスをご覧ください。
次のコードサンプルでは、app/other/
ディレクトリのソースを main
ソースセットの特定のコンポーネントにマッピングして、androidTest
ソースセットのルート ディレクトリを変更しています。
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 get an // error when merging resources. The default directory is 'src/main/res'. res.srcDirs = ['other/res1', 'other/res2'] // Note: You should avoid specifying a directory which 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'] // You should 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' ... } } } ...
Kotlin
android { ... sourceSets { // Encapsulates configurations for the main source set. main { // Changes the directory for Java sources. The default directory is // 'src/main/java'. java.setSrcDirs("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 get an // error when merging resources. The default directory is 'src/main/res'. res.setSrcDirs("other/res1", "other/res2") // Note: You should avoid specifying a directory which 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'] // You should 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") ... } } } ...
ソースセットでビルドする
ソースセット ディレクトリには、特定の設定でのみパッケージ化するコードやリソースを入れておくことができます。たとえば、「demo」プロダクト フレーバーと「debug」ビルドタイプを組み合わせた「demoDebug」ビルド バリアントをビルドしている場合、Gradle はこれらのディレクトリを参照して次の優先順位を付与します。
src/demoDebug/
(ビルド バリアント ソースセット)src/debug/
(ビルドタイプのソースセット)src/demo/
(プロダクト フレーバーのソースセット)src/main/
(メインのソースセット)
注: 複数のプロダクト フレーバーを組み合わせる場合、プロダクト フレーバーの優先順位は各プロダクト フレーバーが属するフレーバー ディメンションによって決まります。android.flavorDimensions
プロパティでフレーバー ディメンションを一覧表示すると、最初に表示されるフレーバー ディメンジョンに属するプロダクト フレーバーが 2 番目のフレーバー ディメンションに属するプロダクト フレーバーより優先順が高く、以降同様に続きます。また、プロダクト フレーバーの組み合わせに対して作成されたソースセットは、個別の各プロダクト フレーバーに属するソースセットよりも優先されます。
Gradle がコードとリソースを組み合わせる際、より優先度の高いソースセットを判別するために上記の順番が用いられます。demoDebug/
ソースセット ディレクトリにはそのビルド バリアント固有のファイルが含まれる可能性が高いため、debug/
で定義されているファイルが demoDebug/
に含まれている場合、Gradle は demoDebug/
ソースセットのファイルを使用します。Gradle では同様に、ビルドタイプとプロダクト フレーバーのソースセットのファイルに対して main/
にある同じファイルよりも高い優先度を付与します。Gradle では、以下のビルドルールを適用するときに、この優先順位が考慮されます。
java/
ディレクトリのすべてのソースコードはコンパイルされて、単一の出力が生成されます。注: 特定のビルド バリアントについては、同じ Java クラスを定義している 2 つ以上のソースセット ディレクトリがある場合、Gradle はビルドエラーをスローします。たとえば、デバッグアプリをビルドする際に
src/debug/Utility.java
とsrc/main/Utility.java
の両方を定義することはできません。Gradle がビルドプロセスの際にこれらの両方のディレクトリを参照し、「duplicate class」エラーをスローするためです。異なるビルドタイプ用に別のバージョンのUtility.java
が必要な場合は、各ビルドタイプで独自のバージョンのファイルを定義し、そのファイルをmain/
ソースセットに含めないようにします。- 複数のマニフェストは単一のマニフェストにマージされ、上記のリストと同じ優先順位が付与されます。つまり、ビルドタイプのマニフェスト設定により、プロダクト フレーバーなどのマニフェスト設定がオーバーライドされます。詳しくは、マニフェストのマージをご覧ください。
values/
ディレクトリのファイルもマージされます。strings.xml
ファイルが 2 つある場合など、2 つのファイルが同じ名前を共有している場合は、上記のリストと同じ優先順位が付与されます。つまり、ビルドタイプのソースセットのファイルで定義されている値により、プロダクト フレーバーなどの同じファイルで定義されている値がオーバーライドされます。res/
とasset/
ディレクトリのリソースは一緒にパッケージ化されます。2 つ以上のソースセットで同じ名前が定義されている複数のリソースがある場合、上記のリストと同じ優先順が付与されます。- 最後に、Gradle はアプリをビルドするときに、ライブラリ モジュールの依存関係に含まれているリソースとマニフェストに最も低い優先順位を付与します。
依存関係の宣言
次のサンプルで示しているように、ビルド バリアントまたはテスト ソースセットの名前を Implementation
キーワードの前に付けることにより、特定のビルド バリアントまたはテスト ソースセットの依存関係を設定できます。
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.0.2' }
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.0.2") }
詳しくは、ビルド依存関係の追加をご覧ください。
署名設定の設定
Gradle では、ビルドの署名設定を明示的に定義しない限りリリースビルドの APK や AAB に署名されません。署名鍵をまだ取得していない場合は、Android Studio を使用してアップロード鍵とキーストアを生成する方法をご覧ください。
Gradle ビルド設定を使用して release ビルドタイプの署名設定を手動で設定するには、次の手順を行います。
- キーストアを作成します。キーストアは一連の秘密鍵を含むバイナリ ファイルです。キーストアは安全な場所に保管する必要があります。
- 秘密鍵を作成します。秘密鍵は、配信するアプリへの署名に使用されます。アプリに含まれることはなく、未承認の第三者に開示することもありません。
-
署名設定をモジュール レベルの
build.gradle
ファイルに追加します。Groovy
... android { ... defaultConfig {...} signingConfigs { release { storeFile file("myreleasekey.keystore") storePassword "password" keyAlias "MyReleaseKey" keyPassword "password" } } buildTypes { release { ... signingConfig signingConfigs.release } } }
Kotlin
... android { ... defaultConfig {...} signingConfigs { create("release") { storeFile = file("myreleasekey.keystore") storePassword = "password" keyAlias = "MyReleaseKey" keyPassword = "password" } } buildTypes { getByName("release") { ... signingConfig = signingConfigs.getByName("release") } } }
注: リリースキーとキーストアのパスワードをビルドファイルに含めることは、セキュリティ上の理由からおすすめできません。代わりに、パスワードを環境変数から取得するか、ビルドプロセスによってパスワードが要求されるようにビルドファイルを設定できます。
パスワードを環境変数から取得する方法:
storePassword System.getenv("KSTOREPWD") keyPassword System.getenv("KEYPWD")
コマンドラインからビルドを開始する場合に、ビルドプロセスによってパスワードが要求されるようにする方法:
storePassword System.console().readLine("\nKeystore password: ") keyPassword System.console().readLine("\nKey password: ")
このプロセスが完了すれば、アプリを配布したり、Google Play で公開したりできます。
警告: キーストアと秘密鍵は安全な場所に保管し、セキュア バックアップを取るようにしてください。Play アプリ署名を使用していて、アップロード鍵を紛失した場合は、Play Console からリセットをリクエストできます。 Play アプリ署名を使用せずにアプリを公開する場合(2021 年 8 月より前に作成したアプリの場合)、アプリ署名鍵を紛失すると、それ以降アプリを更新できなくなります。アプリのすべてのバージョンに同じ署名鍵で署名する必要があるためです。
Wear OS アプリの署名
Wear OS アプリを公開する際は、スマートウォッチの APK と、オプションのスマートフォンの APK の両方を署名する必要があります。Wear OS アプリのパッケージ化と署名について詳しくは、Wear アプリのパッケージ化と配布をご覧ください。