Android ビルドシステムは、アプリリソースとソースコードをコンパイルして、テスト、デプロイ、署名、配布が可能な APK または Android App Bundle にパッケージ化します。Android Studio は、高度なビルド ツールキットである Gradle を使用してビルドプロセスの自動化と管理を行う一方で、柔軟なカスタムビルド構成の定義を可能にしています。各ビルド構成でそれぞれ独自のコードとリソースのセットを定義しつつ、アプリのすべてのバージョンに共通する部分を再利用できます。Android Plugin for Gradle は、ビルド ツールキットと連携して、Android アプリのビルドとテストに固有のプロセスと構成可能な設定を提供します。
Gradle と Android プラグインは Android Studio から独立して実行されます。つまり、Android Studio から、使用しているマシンのコマンドラインから、または Android Studio がインストールされていないマシン（継続的インテグレーション サーバーなど）のコマンドラインから、Android アプリをビルドできます。Android Studio を使用していない場合は、コマンドラインからアプリをビルドして実行する方法についてご確認ください。コマンドライン、リモートマシン、Android Studio のいずれからプロジェクトをビルドした場合でも、ビルドの出力は同じになります。
注: Gradle と Android プラグインは Android Studio から独立して実行されるため、各ビルドツールはそれぞれ個別にアップデートする必要があります。Gradle と Android プラグインをアップデートする方法については、リリースノートをご覧ください。
Android ビルドシステムは柔軟であり、アプリの主要ソースファイルを変更せずに、カスタムビルド構成を設定することができます。このセクションでは、Android ビルドシステムの仕組みと、Android ビルドシステムを通じて複数のビルド設定をカスタマイズ、自動化する方法について説明します。単にアプリをデプロイする方法については、Android Studio からのビルドと実行をご覧ください。Android Studio を使用してカスタムビルド設定の作成をすぐに開始する場合は、ビルド バリアントの設定をご覧ください。
ビルドプロセス
ビルドプロセスには、プロジェクトを Android Application Package（APK）または Android App Bundle（AAB）に変換するさまざまなツールとプロセスが含まれます。ビルドプロセスは非常に柔軟であるため、内部的にどのような処理が行われているかを理解することは有益です。
図 1. 一般的な Android アプリ モジュールのビルドプロセス。
図 1 に示した一般的な Android アプリ モジュールのビルドプロセスの場合、通常は次のようなステップからなります。
- コンパイラが、ソースコードを DEX（Dalvik Executable）ファイルに変換します。このファイルには、Android デバイス上で実行されるバイトコードが格納されます。ソースコード以外の要素はすべてコンパイル済みリソースに変換されます。
- Packager が、選択されたビルド ターゲットに応じて、DEX ファイルとコンパイル済みリソースを APK または AAB に結合します。アプリを Android デバイスにインストールするか、Google Play などのストアに配布するには、APK または AAB に署名する必要があります。
- Packager は、デバッグ キーストアまたはリリース キーストアを使用して、APK または AAB に署名します。
- アプリのデバッグ バージョン（テストやプロファイリングのみを目的とするアプリ）をビルドする場合、Packager はデバッグ キーストアを使用してアプリに署名します。Android Studio は、デバッグ キーストアを使用して新しいプロジェクトを自動的に構成します。
- アプリのリリース バージョン（外部への公開を目的とするアプリ）をビルドする場合、Packager は、リリース キーストア（構成する必要があります）を使用してアプリに署名します。リリース キーストアを作成するには、Android Studio でアプリに署名する方法をご覧ください。
- 最終 APK を生成する前に、Packager は zipalign ツールを使用してアプリを最適化し、アプリがデバイス上で実行されるときのメモリ使用量を削減します。
ビルドプロセスの最後に生成されるアプリのデバッグ APK またはリリース APK を使用して、デプロイ、テスト、外部ユーザーへのリリースを行うことができます。
Android ビルドの用語集
Gradle と Android プラグインを使用すると、以下のビルド要素を設定できます。
- ビルドタイプ
- ビルドタイプは、アプリをビルドしてパッケージ化する際に Gradle が使用する特定のプロパティを定義するものです。一般的に、ビルドタイプは開発ライフサイクルの各段階に応じて構成されます。たとえば、debug ビルドタイプの場合は、デバッグ オプションが有効化され、デバッグキーを使用してアプリに署名します。release ビルドタイプの場合は、圧縮と難読化が行われ、配布するためにリリースキーを使用してアプリに署名します。アプリをビルドするには、少なくとも 1 つのビルドタイプを定義する必要があります。Android Studio は、デフォルトで debug ビルドタイプと release ビルドタイプを作成します。アプリのパッケージ設定のカスタマイズを開始する場合は、ビルドタイプの設定をご覧ください。
- プロダクト フレーバー
- プロダクト フレーバーは、アプリの無料版や有料版など、ユーザーにリリースする各アプリ バージョンを示します。プロダクト フレーバーをカスタマイズすることで、異なるコードやリソースを使用しつつ、すべてのアプリ バージョンに共通する部分を共有し再利用できます。プロダクト フレーバーはオプションであり、手動で作成する必要があります。さまざまなアプリ バージョンの作成を開始する場合は、プロダクト フレーバーの設定をご覧ください。
- ビルド バリアント
- ビルド バリアントは、ビルドタイプとプロダクト フレーバーを組み合わせたものです。Gradle はこの構成を使用してアプリをビルドします。ビルド バリアントを利用することで、開発時にはプロダクト フレーバーのデバッグ バージョンをビルドしつつ、配布時にはプロダクト フレーバーの署名付きリリース バージョンをビルドすることができます。ビルド バリアントは直接設定するものではなく、ビルド バリアントを構成するビルドタイプとプロダクト フレーバーを設定します。追加のビルドタイプまたはプロダクト フレーバーを作成すると、それに応じてビルド バリアントも追加作成されます。ビルド バリアントを作成、管理する方法については、ビルド バリアントの設定をご覧ください。
- マニフェスト エントリ
- ビルド バリアント構成内で、マニフェスト ファイルの一部のプロパティ値を指定できます。このビルド値は、マニフェスト ファイル内の既存の値をオーバーライドします。これは、異なるアプリ名、最小 SDK バージョン、ターゲット SDK バージョンを使用してアプリの複数のバリアントを生成する場合に役立ちます。複数のマニフェストが存在する場合、Gradle はマニフェスト設定をマージします。
- 依存関係
- ビルドシステムは、ローカル ファイル システムやリモート リポジトリのプロジェクト依存関係を管理します。これにより、依存関係のバイナリ パッケージを手動で検索してダウンロードしたり、プロジェクト ディレクトリにコピーしたりする必要がなくなります。詳細については、ビルド依存関係を追加するをご覧ください。
- 署名
- ビルドシステムを使用すると、ビルド構成内で署名設定を指定して、ビルドプロセス中に自動的にアプリに署名できます。デバッグ バージョンの場合、ビルドシステムは、既知の認証情報を使用してデフォルトのキーと証明書で署名を行い、ビルド時にパスワード プロンプトが表示されないようにします。リリース バージョンの場合、対象ビルドの署名設定を明示的に定義していない限り、署名は行いません。リリースキーがない場合は、リリースキーを生成できます。生成方法については、アプリに署名するをご覧ください。
- コードとリソースの圧縮
- ビルドシステムを使用すると、各ビルド バリアントに対してそれぞれ異なる ProGuard ルールファイルを指定できます。アプリをビルドする際、ビルドシステムは適切なルールセットを適用し、R8 などの組み込みの圧縮ツールを使用してコードとリソースを圧縮します。
- 複数 APK のサポート
- ビルドシステムを使用すると、それぞれが特定の画面密度またはアプリケーション バイナリ インターフェース（ABI）に必要なコードとリソースのみを含む各種の APK を自動的にビルドできます。詳細については、複数の APK をビルドするをご覧ください。なお、推奨されるアプローチは単一の AAB をリリースすることです。このアプローチでは、画面密度と ABI に加えて言語でも分割が可能であり、複数のアーティファクトを Google Play にアップロードする際の手間を削減できます。
ビルド構成ファイル
カスタムビルド構成を作成するには、1 つまたは複数のビルド構成ファイル（build.gradle ファイル）に変更を加える必要があります。このプレーン テキスト ファイルは、ドメイン固有言語（DSL）を使用しており、Groovy を使用してビルドロジックを記述、処理します。Groovy は Java 仮想マシン（JVM）用の動的言語です。Android Plugin for Gradle には必要な DSL 要素のほとんどが導入されているため、ビルド設定を開始する際、Groovy に関する知識は必要ありません。Android プラグイン DSL の詳細については、DSL リファレンス ドキュメントをご覧ください。
新しいプロジェクトを開始すると、図 2 のように、Android Studio が一部のファイルを自動的に作成し、適切なデフォルト値に基づいて、ファイルを設定します。
図 2. Android アプリ モジュールのデフォルト プロジェクト構造。
Android アプリの標準プロジェクト構造には、数種類の Gradle ビルド構成ファイルが含まれています。ビルドの設定を開始する前に、各ファイルのスコープと目的、定義する必要のある基本的な DSL 要素について理解しておくことが重要です。
Gradle 設定ファイル
ルート プロジェクト ディレクトリにある settings.gradle ファイルは、プロジェクト レベルのリポジトリ設定を定義します。このファイルに基づいて、Gradle は、アプリをビルドする際に含める必要のあるモジュールを識別します。ほとんどのプロジェクトで、このファイルはデフォルトで次のようになっています。
Groovy
pluginManagement {
/**
* The pluginManagement {repositories {...}} block configures the
* repositories Gradle uses to search or download the Gradle plugins and
* their transitive dependencies. Gradle pre-configures support for remote
* repositories such as JCenter, Maven Central, and Ivy. You can also use
* local repositories or define your own remote repositories. The code below
* defines the Gradle Plugin Portal, Google's Maven repository,
* and the Maven Central Repository as the repositories Gradle should use to look for its dependencies.
*/
repositories {
gradlePluginPortal()
google()
mavenCentral()
}
}
dependencyResolutionManagement {
/**
* The dependencyResolutionManagement { repositories {...}}
* block is where you configure the repositories and dependencies used by
* all modules in your project, such as libraries that you are using to
* create your application. However, you should configure module-specific
* dependencies in each module-level build.gradle file. For new projects,
* Android Studio includes Google's Maven repository
* and the Maven Central Repository by
* default, but it does not configure any dependencies (unless you select a
* template that requires some).
*/
repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS)
repositories {
google()
mavenCentral()
}
}
rootProject.name = "My Application"
include ‘:app’
Kotlin
pluginManagement {
/**
* The pluginManagement {repositories {...}} block configures the
* repositories Gradle uses to search or download the Gradle plugins and
* their transitive dependencies. Gradle pre-configures support for remote
* repositories such as JCenter, Maven Central, and Ivy. You can also use
* local repositories or define your own remote repositories. The code below
* defines the Gradle Plugin Portal, Google's Maven repository,
* and the Maven Central Repository as the repositories Gradle should use to look for its dependencies.
*/
repositories {
gradlePluginPortal()
google()
mavenCentral()
}
}
dependencyResolutionManagement {
/**
* The dependencyResolutionManagement { repositories {...}}
* block is where you configure the repositories and dependencies used by
* all modules in your project, such as libraries that you are using to
* create your application. However, you should configure module-specific
* dependencies in each module-level build.gradle file. For new projects,
* Android Studio includes Google's Maven repository and the
* Maven Central Repository by
* default, but it does not configure any dependencies (unless you select a
* template that requires some).
*/
repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS)
repositories {
google()
mavenCentral()
}
}
rootProject.name = "My Application"
include(":app")
マルチモジュールのプロジェクトの場合、最終ビルドに含める必要のある各モジュールを指定する必要があります。
トップレベル ビルドファイル
ルート プロジェクト ディレクトリにあるトップレベルの build.gradle ファイルは、プロジェクト内のすべてのモジュールに適用される依存関係を定義します。デフォルトでは、トップレベル ビルドファイルは plugins ブロックにより、プロジェクト内のすべてのモジュールに共通する Gradle 依存関係を定義します。また、トップレベル ビルドファイルには、ビルド ディレクトリをクリーンアップするコードが含まれています。次のコードサンプルは、新しいプロジェクトを作成した後にトップレベルの build.gradle ファイル内で見つけることができるデフォルト設定と DSL 要素を示しています。
Groovy
plugins {
/**
* You should use `apply false` in the top-level build.gradle file
* to add a Gradle plugin as a build dependency, but not apply it to the
* current (root) project. You should not use `apply false` in sub-projects.
* For more information, see
* Applying external plugins with same version to subprojects.
*/
id 'com.android.application' version '7.2.0' apply false
id 'com.android.library' version '7.2.0' apply false
id 'org.jetbrains.kotlin.android' version '1.6.10' apply false
}
task clean(type: Delete) {
delete rootProject.buildDir
}
Kotlin
plugins {
/**
* You should use `apply false` in the top-level build.gradle file
* to add a Gradle plugin as a build dependency, but not apply it to the
* current (root) project. You should not use `apply false` in sub-projects.
* For more information, see
* Applying external plugins with same version to subprojects.
*/
id("com.android.application") version "7.1.0-beta02" apply false
id("com.android.library") version "7.1.0-beta02" apply false
id("org.jetbrains.kotlin.android") version "1.5.30" apply false
}
tasks.register("clean", Delete::class) {
delete(rootProject.buildDir)
}
プロジェクト レベルのプロパティを構成する
複数のモジュールを含む Android プロジェクトの場合は、プロジェクト レベルで特定のプロパティを定義し、それをすべてのモジュールで共有すると便利です。そのためには、トップレベルの build.gradle ファイル内の ext ブロックで、追加のプロパティを定義します。
Groovy
// This block encapsulates custom properties and makes them available to all
// modules in the project. The following are only a few examples of the types
// of properties you can define.
ext {
sdkVersion = 28
// You can also create properties to specify versions for dependencies.
// Having consistent versions between modules can avoid conflicts with behavior.
supportLibVersion = "28.0.0"
...
}
...
Kotlin
// This block encapsulates custom properties and makes them available to all
// modules in the project. The following are only a few examples of the types
// of properties you can define.
ext {
extra["compileSdkVersion"] = 28
// You can also create properties to specify versions for dependencies.
// Having consistent versions between modules can avoid conflicts with behavior.
extra["supportLibVersion"] = "28.0.0"
...
}
...
同一プロジェクト内の個々のモジュールからこのプロパティにアクセスするには、モジュールの build.gradle ファイル内で次の構文を使用します（このファイルの詳細については後述します）。
Groovy
android {
// Use the following syntax to access properties you defined at the project level:
// rootProject.ext.property_name
compileSdkVersion rootProject.ext.compileSdkVersion
...
}
...
dependencies {
implementation "com.android.support:appcompat-v7:${rootProject.ext.supportLibVersion}"
...
}
Kotlin
android {
// Use the following syntax to access properties you defined at the project level:
// rootProject.extra["property_name"]
compileSdk = rootProject.extra["sdkVersion"]
// Alternatively, you can access properties using a type safe delegate:
val sdkVersion: Int by rootProject.extra
...
compileSdk = sdkVersion
}
...
dependencies {
implementation("com.android.support:appcompat-v7:${rootProject.ext.supportLibVersion}")
...
}
注: Gradle では、プロジェクト レベルのプロパティをモジュール レベルで定義することもできますが、その場合、プロパティを共有するモジュールが結合されてしまうため、この方法は避けてください。モジュールが結合すると、後でスタンドアロンのプロジェクトとして個々のモジュールをエクスポートするのが困難になります。そのため、Gradle は、並列プロジェクト実行を使用してマルチモジュール ビルドを高速化することが事実上不可能になります。
モジュール レベル ビルドファイル
各 project/module/ ディレクトリにあるモジュール レベルの build.gradle ファイルを使用すると、そのファイルが属する個々のモジュールのビルド設定を指定できます。モジュール レベルでビルド設定を指定した場合、追加のビルドタイプやプロダクト フレーバーなど、カスタム パッケージ オプションを設定することで、main/ アプリ マニフェスト内やトップレベルの build.gradle ファイル内の設定をオーバーライドできます。
把握しておくべき基本的な DSL 要素と設定の概要について、サンプル Android アプリ モジュールの build.gradle ファイルに示します。
Groovy
/**
* The first line in the build configuration applies the Android plugin for
* Gradle to this build and makes the android block available to specify
* Android-specific build options.
*/
plugins {
id 'com.android.application'
}
/**
* The android block is where you configure all your Android-specific
* build options.
*/
android {
/**
* The app's namespace. Used primarily to access app resources.
*/
namespace 'com.example.myapp'
/**
* compileSdkVersion specifies the Android API level Gradle should use to
* compile your app. This means your app can use the API features included in
* this API level and lower.
*/
compileSdkVersion 28
/**
* The defaultConfig block encapsulates default settings and entries for all
* build variants, and can override some attributes in main/AndroidManifest.xml
* dynamically from the build system. You can configure product flavors to override
* these values for different versions of your app.
*/
defaultConfig {
// Uniquely identifies the package for publishing.
applicationId 'com.example.myapp'
// Defines the minimum API level required to run the app.
minSdkVersion 15
// Specifies the API level used to test the app.
targetSdkVersion 28
// Defines the version number of your app.
versionCode 1
// Defines a user-friendly version name for your app.
versionName "1.0"
}
/**
* The buildTypes block is where you can configure multiple build types.
* By default, the build system defines two build types: debug and release. The
* debug build type is not explicitly shown in the default build configuration,
* but it includes debugging tools and is signed with the debug key. The release
* build type applies Proguard settings and is not signed by default.
*/
buildTypes {
/**
* By default, Android Studio configures the release build type to enable code
* shrinking, using minifyEnabled, and specifies the default Proguard rules file.
*/
release {
minifyEnabled true // Enables code shrinking for the release build type.
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
}
/**
* The productFlavors block is where you can configure multiple product flavors.
* This allows you to create different versions of your app that can
* override the defaultConfig block with their own settings. Product flavors
* are optional, and the build system does not create them by default.
*
* This example creates a free and paid product flavor. Each product flavor
* then specifies its own application ID, so that they can exist on the Google
* Play Store, or an Android device, simultaneously.
*
* If you declare product flavors, you must also declare flavor dimensions
* and assign each flavor to a flavor dimension.
*/
flavorDimensions "tier"
productFlavors {
free {
dimension "tier"
applicationId 'com.example.myapp.free'
}
paid {
dimension "tier"
applicationId 'com.example.myapp.paid'
}
}
}
/**
* The dependencies block in the module-level build configuration file
* specifies dependencies required to build only the module itself.
* To learn more, go to Add build dependencies.
*/
dependencies {
implementation project(":lib")
implementation 'com.android.support:appcompat-v7:28.0.0'
implementation fileTree(dir: 'libs', include: ['*.jar'])
}
Kotlin
/**
* The first section in the build configuration applies the Android plugin for
* Gradle to this build and makes the android block available to specify
* Android-specific build options.
*/
plugins {
id("com.android.application")
}
/**
* The android block is where you configure all your Android-specific
* build options.
*/
android {
/**
* The app's namespace. Used primarily to access app resources.
*/
namespace = "com.example.myapp"
/**
* compileSdkVersion specifies the Android API level Gradle should use to
* compile your app. This means your app can use the API features included in
* this API level and lower.
*/
compileSdk = 28
/**
* buildToolsVersion specifies the version of the SDK build tools, command-line
* utilities, and compiler that Gradle should use to build your app. You need to
* download the build tools using the SDK Manager.
*
* This property is optional because the plugin uses a recommended version of
* the build tools by default.
*/
buildToolsVersion = "30.0.2"
/**
* The defaultConfig block encapsulates default settings and entries for all
* build variants, and can override some attributes in main/AndroidManifest.xml
* dynamically from the build system. You can configure product flavors to override
* these values for different versions of your app.
*/
defaultConfig {
// Uniquely identifies the package for publishing.
applicationId = "com.example.myapp"
// Defines the minimum API level required to run the app.
minSdk = 15
// Specifies the API level used to test the app.
targetSdk = 28
// Defines the version number of your app.
versionCode = 1
// Defines a user-friendly version name for your app.
versionName = "1.0"
}
/**
* The buildTypes block is where you can configure multiple build types.
* By default, the build system defines two build types: debug and release. The
* debug build type is not explicitly shown in the default build configuration,
* but it includes debugging tools and is signed with the debug key. The release
* build type applies Proguard settings and is not signed by default.
*/
buildTypes {
/**
* By default, Android Studio configures the release build type to enable code
* shrinking, using minifyEnabled, and specifies the default Proguard rules file.
*/
getByName("release") {
isMinifyEnabled = true // Enables code shrinking for the release build type.
proguardFiles(
getDefaultProguardFile("proguard-android.txt"),
"proguard-rules.pro"
)
}
}
/**
* The productFlavors block is where you can configure multiple product flavors.
* This allows you to create different versions of your app that can
* override the defaultConfig block with their own settings. Product flavors
* are optional, and the build system does not create them by default.
*
* This example creates a free and paid product flavor. Each product flavor
* then specifies its own application ID, so that they can exist on the Google
* Play Store, or an Android device, simultaneously.
*
* If you declare product flavors, you must also declare flavor dimensions
* and assign each flavor to a flavor dimension.
*/
flavorDimensions = "tier"
productFlavors {
create("free") {
dimension = "tier"
applicationId = "com.example.myapp.free"
}
create("paid") {
dimension = "tier"
applicationId = "com.example.myapp.paid"
}
}
}
/**
* The dependencies block in the module-level build configuration file
* specifies dependencies required to build only the module itself.
* To learn more, go to Add build dependencies.
*/
dependencies {
implementation(project(":lib"))
implementation("com.android.support:appcompat-v7:28.0.0")
implementation(fileTree(mapOf("dir" to "libs", "include" to listOf("*.jar"))))
}
Gradle プロパティ ファイル
Gradle には、ルート プロジェクト ディレクトリにプロパティ ファイルも 2 つあります。このファイルを使用することで、Gradle ビルド ツールキット自体の設定を指定できます。
-
gradle.properties - Gradle デーモンの最大ヒープサイズなど、プロジェクト レベルの Gradle 設定を指定できます。詳細については、ビルド環境をご覧ください。
-
local.properties - 以下の項目など、ビルドシステムのローカル環境プロパティを設定します。
ndk.dir- NDK へのパス。このプロパティのサポートは終了しました。ダウンロードしたバージョンの NDK はすべて、Android SDK ディレクトリ内のndkディレクトリにインストールされます。sdk.dir- SDK へのパス。cmake.dir- CMake へのパス。ndk.symlinkdir- Android Studio 3.5 以降では、インストールされている NDK パスよりも短くできる、NDK へのシンボリック リンクが作成されます。
NDK を短いパスに再マッピングする（Windows のみ）
Windows でパスが長いことによる問題でよくあるのは、インストールされた NDK フォルダ内のツール（ld.exe など）のパスが非常に深くなっても、ツールが長いパスを適切にサポートしないことです。
local.properties では、プロパティ ndk.symlinkdir を設定して、Gradle プラグインが NDK へのシンボリック リンクを作成するようにリクエストできます。シンボリック リンクのパスは、既存の NDK フォルダより短くできます。たとえば ndk.symlinkdir = C:\ は、C:\ndk\19.0.5232133 というシンボリック リンクになります。
プロジェクトと Gradle ファイルを同期する
プロジェクト内のビルド構成ファイルに変更を加えた場合、プロジェクト ファイルを同期するよう Android Studio から求められます。同期すると、ビルド設定の変更をインポートして、設定がビルドエラーを引き起こさないか確認するチェックを実行できるようになります。
プロジェクト ファイルを同期するには、図 3 に示すように、変更を加えたときに表示される通知バーで [Sync Now] をクリックするか、メニューバーから [Sync Project] 
をクリックします。Android Studio が設定に関するエラー（たとえば、指定されている compileSdkVersion よりも上位の API レベルでなければ利用できない API 機能をソースコードが使用しているなど）を認識した場合、問題の説明を記載した [Messages] ウィンドウが表示されます。
図 3. Android Studio でのプロジェクトとビルド構成ファイルの同期。
ソースセット
Android Studio は、各モジュールのソースコードとリソースをソースセットとして論理的にグループ化します。モジュールの main/ ソースセットには、すべてのビルド バリアントが使用するコードとリソースが含まれます。追加のソースセット ディレクトリはオプションであり、新しいビルド バリアントを設定しても、そのソースセット ディレクトリを Android Studio が自動的に作成することはありません。しかし、main/ と同様のソースセットを作成しておくと、アプリの特定バージョンをビルドするときにのみ Gradle が使用するファイルとリソースを整理できます。
-
src/main/ - このソースセットには、すべてのビルド バリアントに共通するコードとリソースが含まれています。
-
src/buildType/ - 特定のビルドタイプだけを対象とするコードとリソースを含めるには、このソースセットを作成します。
-
src/productFlavor/ - 特定のプロダクト フレーバーだけを対象とするコードとリソースを含めるには、このソースセットを作成します。
注: 複数のプロダクト フレーバーを組み合わせるようにビルドを設定した場合、フレーバー ディメンション間のプロダクト フレーバーの組み合わせごとにソースセット ディレクトリを作成できます（
src/productFlavor1ProductFlavor2/）。 -
src/productFlavorBuildType/ - 特定のビルド バリアントだけを対象とするコードとリソースを含めるには、このソースセットを作成します。
たとえば、アプリの「fullDebug」バージョンを生成する場合、ビルドシステムは以下のソースセットのコード、設定、リソースをマージします。
src/fullDebug/（ビルド バリアントのソースセット）src/debug/（ビルドタイプのソースセット）src/full/（プロダクト フレーバーのソースセット）src/main/（メインのソースセット）
注: Android Studio 内で新しいファイルまたはディレクトリを作成する際、[File] > [New] メニュー オプションを使用すると、特定のソースセット用のファイルまたはディレクトリを作成できます。ビルド設定に応じてソースセットを選択でき、必要なディレクトリが存在しない場合は、Android Studio が自動的に作成します。
異なるソースセット内に同一ファイルの別バージョンが含まれている場合、Gradle は次の優先順位に基づいて、使用するファイルを決定します（左側のソースセットが右側のソースセットのファイルや設定をオーバーライドします）。
ビルド バリアント > ビルドタイプ > プロダクト フレーバー > メイン ソースセット > ライブラリ依存関係
これにより、Gradle は、ビルドしようとしているビルド バリアントに固有のファイルを使用しつつ、他のアプリ バージョンと共通するアクティビティ、アプリロジック、リソースを再利用できるようになります。Gradle が複数のマニフェストをマージする際も同じ優先順位が使用されるため、ビルド バリアントごとに最終マニフェスト内でさまざまなコンポーネントやパーミッションを定義できます。カスタム ソースセットの作成方法については、ビルド バリアントのソースセットの作成をご覧ください。