Android ビルドシステムは、アプリリソースとソースコードをコンパイルして、テスト、デプロイ、署名、配布が可能な APK または Android App Bundle にパッケージ化します。
Android Studio は、高度なビルド ツールキットである Gradle を使用してビルドプロセスの自動化と管理を行う一方で、柔軟なカスタムビルド構成の定義を可能にしています。各ビルド構成でそれぞれ独自のコードとリソースのセットを定義しつつ、アプリのすべてのバージョンに共通する部分を再利用できます。Android Gradle プラグインは、ビルド ツールキットと連携して、Android アプリのビルドとテストに固有のプロセスと構成可能な設定を提供します。
Gradle と Android Gradle プラグインは Android Studio から独立して実行されます。つまり、Android Studio から、使用しているマシンのコマンドラインから、または Android Studio がインストールされていないマシン（継続的インテグレーション サーバーなど）のコマンドラインから、Android アプリをビルドできます。
Android Studio を使用しない場合は、コマンドラインからアプリをビルドして実行する方法をご確認ください。コマンドライン、リモートマシン、Android Studio のいずれからプロジェクトをビルドした場合でも、ビルドの出力は同じになります。
注: Gradle と Android Gradle プラグインは Android Studio から独立して実行されるため、各ビルドツールはそれぞれ個別にアップデートする必要があります。Gradle と Android Gradle プラグインをアップデートする方法については、リリースノートをご覧ください。
Android ビルドシステムは柔軟であるため、アプリの主要なソースファイルを変更せずにカスタムビルド構成を作成できます。このページでは、Android ビルドシステムの仕組みと、Android ビルドシステムを通じて複数のビルド構成をカスタマイズし、自動化する方法について説明します。アプリのデプロイについて詳しくは、アプリをビルドして実行するをご覧ください。Android Studio を使用してカスタムビルド構成の作成をすぐに開始するには、ビルド バリアントを設定するをご覧ください。
ビルドプロセス
ビルドプロセスには、プロジェクトを Android Application Package（APK）または Android App Bundle（AAB）に変換するさまざまなツールとプロセスが含まれます。
Android Gradle プラグインはビルドプロセスの大部分を行いますが、ビルドプロセスの特定の側面を理解し、要件に合わせてビルドを調整できるようにすると便利です。
プロジェクトによってビルドの目標が異なることがあります。たとえば、サードパーティ ライブラリのビルドでは、AAR ライブラリまたは JAR ライブラリが生成されます。ただし、アプリは最も一般的なタイプのプロジェクトであり、アプリ プロジェクトのビルドでは、アプリのデバッグまたはリリース用の APK または AAB が生成され、これを外部ユーザーにデプロイ、テスト、またはリリースできます。
このページではアプリ開発に焦点を当てていますが、ビルドの手順やコンセプトの多くは、ほとんどのビルドタイプに共通です。
Android ビルドの用語集
Gradle と Android Gradle プラグインを使用すると、以下のビルド要素を構成できます。
- ビルドタイプ
-
ビルドタイプは、アプリをビルドしてパッケージ化する際に Gradle が使用する特定のプロパティを定義するものです。一般的に、ビルドタイプは開発ライフサイクルの各段階に応じて構成されます。
たとえば、debug ビルドタイプの場合は、デバッグ オプションが有効化され、デバッグキーを使用してアプリに署名します。release ビルドタイプの場合は、圧縮と難読化が行われ、配布するためにリリースキーを使用してアプリに署名します。
アプリをビルドするには、少なくとも 1 つのビルドタイプを定義する必要があります。Android Studio は、デフォルトで debug ビルドタイプと release ビルドタイプを作成します。アプリのパッケージ設定のカスタマイズを開始する場合は、ビルドタイプの設定をご覧ください。
- プロダクト フレーバー
- プロダクト フレーバーは、アプリの無料版や有料版など、ユーザーにリリースできるさまざまなアプリ バージョンを示します。プロダクト フレーバーをカスタマイズすることで、さまざまなコードとリソースを使用しつつ、すべてのアプリ バージョンに共通する部分を共有し、再利用できます。プロダクト フレーバーはオプションであり、手動で作成する必要があります。さまざまなアプリ バージョンの作成を開始する場合は、プロダクト フレーバーの設定をご覧ください。
- ビルド バリアント
- ビルド バリアントは、ビルドタイプとプロダクト フレーバーを組み合わせたものです。Gradle はこの構成を使用してアプリをビルドします。ビルド バリアントを使用すると、開発時にプロダクト フレーバーのデバッグ バージョンをビルドし、配布時にプロダクト フレーバーの署名付きリリース バージョンをビルドできます。ビルド バリアントは直接構成するものではなく、ビルド バリアントを形成するビルドタイプとプロダクト フレーバーを構成します。追加のビルドタイプまたはプロダクト フレーバーを作成すると、それに応じてビルド バリアントも追加作成されます。ビルド バリアントを作成、管理する方法については、ビルド バリアントを設定するをご覧ください。
- マニフェスト エントリ
- ビルド バリアント構成内で、マニフェスト ファイルの一部のプロパティ値を指定できます。このビルド値は、マニフェスト ファイル内の既存の値をオーバーライドします。これは、異なるアプリ名、最小 SDK バージョン、ターゲット SDK バージョンを使用してアプリの複数のバリアントを生成する場合に役立ちます。複数のマニフェストが存在する場合、マニフェスト マージツールがマニフェスト設定をマージします。
- 依存関係
- ビルドシステムは、ローカル ファイル システムやリモート リポジトリのプロジェクト依存関係を管理します。つまり、依存関係のバイナリ パッケージを手動で検索してダウンロードしたり、プロジェクト ディレクトリにコピーしたりする必要はありません。詳細については、ビルド依存関係を追加するをご覧ください。
- 署名
- ビルドシステムを使用すると、ビルド構成で署名設定を指定して、ビルドプロセス中に自動的にアプリに署名できます。デバッグ バージョンの場合、ビルドシステムは、既知の認証情報を使用してデフォルトのキーと証明書で署名を行い、ビルド時にパスワード プロンプトが表示されないようにします。リリース バージョンの場合、対象ビルドの署名設定を明示的に定義していない限り、署名は行いません。リリースキーがない場合は、アプリに署名するに記載されているとおり、リリースキーを生成できます。署名付きリリースビルドは、ほとんどのアプリストアでアプリを配布するために必要です。
- コードとリソースの圧縮
- ビルドシステムを使用すると、ビルド バリアントごとに異なる ProGuard ルールファイルを指定できます。アプリをビルドする際、ビルドシステムは適切なルールセットを適用し、R8 などの組み込みの圧縮ツールを使用してコードとリソースを圧縮します。コードとリソースを圧縮すると、APK や AAB のサイズを縮小できます。
- 複数 APK のサポート
- ビルドシステムを使用すると、特定の画面密度またはアプリケーション バイナリ インターフェース（ABI）に必要なコードとリソースのみを含む、さまざまな APK を自動的にビルドできます。詳細については、複数の APK をビルドするをご覧ください。ただし、単一の AAB をリリースすることをおすすめします。このアプローチでは、画面密度と ABI に加えて言語でも分割でき、Google Play に複数のアーティファクトをアップロードせずに済みます。2021 年 8 月以降に送信された新しいアプリはすべて、AAB を使用する必要があります。
ビルド構成ファイル
カスタムビルド構成を作成するには、1 つまたは複数のビルド構成ファイル（build.gradle ファイル）に変更を加える必要があります。この書式なしテキスト ファイルは、ドメイン固有言語（DSL）を使用して、Java 仮想マシン（JVM）用の動的言語である Groovy か、Kotlin 言語のフレーバーである Kotlin スクリプトでビルドロジックを記述し、処理します。
Android Gradle プラグインには必要な DSL 要素のほとんどが導入されているため、ビルドの構成を開始する際、Groovy や Kotlin スクリプトに関する知識は必要ありません。Android Gradle プラグインの DSL の詳細については、Groovy の DSL リファレンス ドキュメントをご覧ください。Kotlin スクリプトは基となる Gradle Kotlin DSL にも依存します。
新しいプロジェクトを開始すると、図 1 のように、Android Studio が一部のファイルを自動的に作成し、適切なデフォルト値に基づいて、ファイルを設定します。
Android アプリの標準プロジェクト構造には、数種類の Gradle ビルド構成ファイルが含まれています。ビルドの構成を開始する前に、各ファイルのスコープと目的、定義する必要のある基本的な DSL 要素について理解しておくことが重要です。
Gradle 設定ファイル
settings.gradle ファイル（Groovy の場合）または settings.gradle.kts
ファイル（Kotlin スクリプトの場合）は、ルート プロジェクト ディレクトリにあります。この設定ファイルは、プロジェクト レベルのリポジトリ設定を定義し、アプリのビルド時に含めるモジュールを 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 ファイル（Groovy の場合）または build.gradle.kts ファイル（Kotlin スクリプトの場合）は、ルート プロジェクト ディレクトリにあります。このファイルは、プロジェクト内のすべてのモジュールに適用される依存関係を定義します。デフォルトでは、トップレベル ビルドファイルは plugins ブロックにより、プロジェクト内のすべてのモジュールに共通する Gradle 依存関係を定義します。また、トップレベル ビルドファイルには、ビルド ディレクトリをクリーンアップするコードが含まれています。
次のコードサンプルは、新しいプロジェクトを作成した後の、トップレベルの build.gradle ファイルのデフォルト設定と DSL 要素を示しています。
Groovy
plugins {
/**
* 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. Don't use `apply false` in sub-projects. For more information,
* see Applying external plugins with same version to subprojects.
*/
id 'com.android.application' version '7.3.0' apply false
id 'com.android.library' version '7.3.0' apply false
id 'org.jetbrains.kotlin.android' version '1.7.20' apply false
}
Kotlin
plugins {
/**
* 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. Don't use `apply false` in sub-projects. For more information,
* see Applying external plugins with same version to subprojects.
*/
id("com.android.application") version "7.3.0" apply false
id("com.android.library") version "7.3.0" apply false
id("org.jetbrains.kotlin.android") version "1.7.20" apply false
}
プロジェクト レベルのプロパティを構成する
複数のモジュールを含む Android プロジェクトの場合は、プロジェクト レベルで特定のプロパティを定義し、それをすべてのモジュールで共有すると便利です。そのためには、トップレベルの build.gradle ファイル（Groovy の場合）または build.gradle.kts ファイル（Kotlin スクリプトの場合）の 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 = 33
// You can also create properties to specify versions for dependencies.
// Having consistent versions between modules can avoid conflicts with behavior.
appcompatVersion = "1.6.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["sdkVersion"] = 33
// You can also create properties to specify versions for dependencies.
// Having consistent versions between modules can avoid conflicts with behavior.
extra["appcompatVersion"] = "1.6.0"
...
}
...
同一プロジェクト内の各モジュールから上記のプロパティにアクセスするには、モジュールの build.gradle ファイル内で次の構文を使用します。
Groovy
android {
// Use the following syntax to access properties you defined at the project level:
// rootProject.ext.property_name
compileSdk rootProject.ext.sdkVersion
...
}
...
dependencies {
implementation "androidx.appcompat:appcompat:${rootProject.ext.appcompatVersion}"
...
}
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("androidx.appcompat:appcompat:${rootProject.ext.appcompatVersion}")
...
}
注: Gradle では、プロジェクト レベルのプロパティをモジュール レベルで定義することもできますが、その場合、プロパティを共有するモジュールが結合されてしまうため、この方法は避けてください。モジュールが結合すると、後でスタンドアロンのプロジェクトとして個々のモジュールをエクスポートすることが困難になります。そのため、Gradle は、並列プロジェクト実行を使用してマルチモジュール ビルドを高速化できなくなります。
モジュール レベル ビルドファイル
モジュール レベルの build.gradle ファイル（Groovy の場合）または build.gradle.kts（Kotlin スクリプトの場合）は、各 project/module/ ディレクトリにあります。このファイルを使用すると、属する個々のモジュールのビルド設定を構成できます。モジュール レベルのビルド設定を構成すると、追加のビルドタイプやプロダクト フレーバーなどのカスタム パッケージ化オプションを指定して、main/ アプリ マニフェストまたはトップレベルの build.gradle ファイルもしくは build.gradle.kts ファイルの設定をオーバーライドできます。
基本的な DSL 要素と設定の概要について、以下のサンプル Android アプリ モジュールの build.gradle ファイルに示します。
Groovy
/**
* The first line in the build configuration applies the Android Gradle plugin
* 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'
/**
* compileSdk 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 33
/**
* 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 21
// Specifies the API level used to test the app.
targetSdk 33
// 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 lets you 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 'androidx.appcompat:appcompat:1.6.0'
implementation fileTree(dir: 'libs', include: ['*.jar'])
}
Kotlin
/**
* The first section in the build configuration applies the Android Gradle plugin
* 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"
/**
* compileSdk 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 = 33
/**
* 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 = 21
// Specifies the API level used to test the app.
targetSdk = 33
// 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 lets you 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("androidx.appcompat:appcompat:1.6.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 を設定して、Android Gradle プラグインが NDK へのシンボリック リンクを作成するようにリクエストします。シンボリック リンクのパスは、既存の NDK フォルダより短くできます。たとえば ndk.symlinkdir = C:\ は、C:\ndk\19.0.5232133 というシンボリック リンクになります。
プロジェクトと Gradle ファイルを同期する
プロジェクト内のビルド構成ファイルに変更を加えた場合、プロジェクト ファイルを同期するよう Android Studio から求められます。同期すると、ビルド構成の変更をインポートして、構成がビルドエラーを引き起こさないか確認するチェックを実行できるようになります。
プロジェクト ファイルを同期するには、変更を加えたときに表示される通知バーで [Sync Now] をクリックするか（図 2 を参照）、メニューバーでプロジェクトの同期アイコン 
をクリックします。Android Studio が構成に関するエラー（compileSdkVersion より上位の API レベルでなければ利用できない API 機能をソースコードが使用しているなど）を検出すると、事象の内容が [Messages] ウィンドウに記載されます。
ソースセット
Android Studio は、各モジュールのソースコードとリソースをソースセットとして論理的にグループ化します。新しいモジュールを作成すると、Android Studio はそのモジュール内に main/ ソースセットを作成します。モジュールの 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 は複数のマニフェストをマージする際も同じ優先順位を使用するため、最終マニフェストでビルド バリアントごとにさまざまなコンポーネントまたは権限を定義できます。カスタム ソースセットの作成について詳しくは、ソースセットの作成をご覧ください。
他のビルドシステム
Bazel を使用して Android アプリを作成することは可能ですが、公式にはサポートされていません。Android Studio は公式には Bazel プロジェクトをサポートしていません。
Bazel を使用するビルドの現在の制限事項については、既知の問題をご覧ください。