Android ビルドシステムは、アプリリソースとソースコードをコンパイルして、テスト、デプロイ、署名、配布が可能な APK または Android App Bundle にパッケージ化します。
Gradle ビルドの概要と Android ビルドの構造では、ビルドのコンセプトと Android アプリの構造について説明しました。ここでは、ビルドを構成します。
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 を使用する必要があります。
Android ビルドの Java バージョン
ソースコードが Java、Kotlin、またはその両方で記述されている場合、ビルドの JDK または Java 言語のバージョンを選択する必要がある場所がいくつかあります。詳しくは、Android ビルドの Java バージョンをご覧ください。
ビルド構成ファイル
カスタムビルド構成を作成するには、1 つ以上のビルド構成ファイルに変更を加える必要があります。これらの書式なしテキスト ファイルは、ドメイン固有言語(DSL)を使用して、Kotlin 言語のフレーバーである Kotlin スクリプトでビルドロジックを記述し、処理します。Java 仮想マシン(JVM)用の動的言語である Groovy を使用してビルドを構成することもできます。
Android Gradle プラグインには必要な DSL 要素のほとんどが導入されているため、ビルドの構成を開始する際、Kotlin スクリプトや Groovy に関する知識は必要ありません。Android Gradle プラグインの DSL の詳細については、DSL リファレンス ドキュメントをご覧ください。Kotlin スクリプトは、基盤となる Gradle Kotlin DSL にも依存します。
新しいプロジェクトを開始すると、Android Studio はこれらのファイルの一部を自動的に作成し、適切なデフォルト値に基づいてファイルを設定します。作成されたファイルの概要については、Android ビルド構造をご覧ください。
Gradle ラッパー ファイル
Gradle ラッパー(gradlew
)は、Gradle 自体をダウンロードして起動する、ソースコードに含まれている小さなアプリケーションです。これにより、ビルド実行の整合性が高まります。デベロッパーはアプリケーション ソースをダウンロードして gradlew
を実行します。これにより、必要な Gradle ディストリビューションがダウンロードされ、Gradle が起動してアプリケーションがビルドされます。
gradle/wrapper/gradle-wrapper.properties
ファイルには、ビルドの実行に使用される Gradle のバージョンを記述するプロパティ distributionUrl
が含まれています。
distributionBase=GRADLE_USER_HOME
distributionPath=wrapper/dists
distributionUrl=https\://services.gradle.org/distributions/gradle-8.0-bin.zip
zipStoreBase=GRADLE_USER_HOME
zipStorePath=wrapper/dists
Gradle 設定ファイル
settings.gradle.kts
ファイル(Kotlin DSL の場合)または settings.gradle
ファイル(Groovy DSL の場合)は、ルート プロジェクト ディレクトリにあります。この設定ファイルは、プロジェクト レベルのリポジトリ設定を定義し、アプリのビルド時に含めるモジュールを Gradle に伝えます。マルチモジュール プロジェクトでは、最終的なビルドに含める各モジュールを指定する必要があります。
ほとんどのプロジェクトで、このファイルはデフォルトで次のようになります。
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. Here we * define 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")
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. Here we * define 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.kts
ファイル(Kotlin DSL の場合)または build.gradle
ファイル(Groovy DSL の場合)は、ルート プロジェクト ディレクトリにあります。通常、プロジェクト内のモジュールで使用されるプラグインの一般的なバージョンを定義します。
次のコードサンプルは、新しいプロジェクトを作成した後の、トップレベルのビルド スクリプトのデフォルト設定と DSL 要素を示しています。
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 "8.7.0" apply false id("com.android.library") version "8.7.0" apply false id("org.jetbrains.kotlin.android") version "2.0.20" apply false }
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 '8.7.0' apply false id 'com.android.library' version '8.7.0' apply false id 'org.jetbrains.kotlin.android' version '2.0.20' apply false }
モジュール レベル ビルドファイル
モジュール レベルの build.gradle.kts
(Kotlin DSL の場合)または build.gradle
(Groovy DSL の場合)ファイルは、各 project/module/
ディレクトリにあります。このファイルを使用すると、属する個々のモジュールのビルド設定を構成できます。モジュール レベルのビルド設定を構成すると、追加のビルドタイプやプロダクト フレーバーなどのカスタム パッケージ化オプションを指定して、main/
アプリ マニフェストまたはトップレベルのビルド スクリプトの設定をオーバーライドできます。
Android SDK の設定
アプリのモジュール レベルのビルドファイルには、コンパイル時、プラットフォームの動作の選択時、アプリが実行される最小バージョンの指定時に使用される Android SDK バージョンを示す設定が含まれています。
-
compileSdk
-
compileSdk
は、ソースコードのコンパイル時に使用可能な Android API と Java API を決定します。最新の Android 機能を使用するには、コンパイル時に最新の Android SDK を使用します。一部の Android プラットフォーム API は、古い API レベルでは使用できない場合があります。 新しい機能の使用を条件付きでガードするか、 AndroidX 互換性ライブラリを使用して、Android API レベルが低いデバイスで新しい機能を使用できます。
各 Android SDK には、アプリケーションで使用できる Java API のサブセットが用意されています。 Java または Kotlin のソースコードで使用できる Java API の表に、Android SDK のバージョンに基づいて使用できる Java API レベルを示します。新しい Java API は、脱糖により以前のバージョンの Android でサポートされています。この脱糖はビルドで有効にする必要があります。
compileSdk
が現在のバージョンの Android Studio、AGP、またはプロジェクトのライブラリ依存関係の要件と競合している場合、Android Studio に警告が表示されます。 -
minSdk
-
minSdk
には、アプリがサポートする Android の最小バージョンを指定します。minSdk
を設定すると、アプリをインストールできるデバイスを制限できます。以前のバージョンの Android をサポートするには、コードに条件チェックを追加したり、AndroidX 互換性ライブラリをより多く使用したりする必要があります。古いバージョンのサポートにかかるメンテナンス コストと、その古いバージョンをまだ使用しているユーザーの割合を比較検討する必要があります。現在のバージョン使用率については、Android Studio の新しいプロジェクト ウィザードのバージョン グラフをご覧ください。
Android Studio でコードを編集しているときや、ビルド中にチェックを実行しているときに、
minSdk
で使用できない API について lint から警告が届きます。これらの問題は、 新しい機能を条件付きにするか、下位互換性のためにAppcompat
を使用して修正する必要があります。 -
targetSdk
-
targetSdk
には次の 2 つの目的があります。- アプリケーションのランタイム動作を設定します。
- テストした Android のバージョンを証明します。
targetSdk
よりも新しいバージョンの Android を搭載したデバイスで実行する場合、Android は互換モードでアプリを実行します。このモードでは、targetSdk
で指定された古いバージョンと同様に動作します。たとえば、API 23 でランタイム権限モデルが導入されたとき、すべてのアプリがすぐにそれを採用できるわけではありません。targetSdk
を 22 に設定することで、これらのアプリは実行時の権限を使用せずに API 23 デバイスで実行でき、最新のcompileSdk
バージョンに含まれる機能を使用できるようになります。Google Play 配信ポリシーでは、 対象 API レベルに関する追加ポリシーが適用されます。targetSdk
の値はcompileSdk
以下にする必要があります。
注: compileSdk
と targetSdk
の値を同じにする必要はありません。次の基本原則に留意してください。
compileSdk
を使用すると、新しい API にアクセスできます。targetSdk
: アプリのランタイム動作を設定しますtargetSdk
はcompileSdk
以下でなければなりません
アプリ モジュールのビルド スクリプトのサンプル
基本的な DSL 要素と設定の概要について、以下のサンプル Android アプリ モジュールのビルド スクリプトに示します。
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") } /** * Locate (and possibly download) a JDK used to build your kotlin * source code. This also acts as a default for sourceCompatibility, * targetCompatibility and jvmTarget. Note that this does not affect which JDK * is used to run the Gradle build itself, and does not need to take into * account the JDK version required by Gradle plugins (such as the * Android Gradle Plugin) */ kotlin { jvmToolchain(11) } /** * 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" } } /** * To override source and target compatibility (if different from the * toolchain JDK version), add the following. All of these * default to the same value as kotlin.jvmToolchain. If you're using the * same version for these values and kotlin.jvmToolchain, you can * remove these blocks. */ //compileOptions { // sourceCompatibility = JavaVersion.VERSION_11 // targetCompatibility = JavaVersion.VERSION_11 //} //kotlinOptions { // jvmTarget = "11" //} } /** * 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.7.0") implementation(fileTree(mapOf("dir" to "libs", "include" to listOf("*.jar")))) }
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' } /** * Locate (and possibly download) a JDK used to build your kotlin * source code. This also acts as a default for sourceCompatibility, * targetCompatibility and jvmTarget. Note that this does not affect which JDK * is used to run the Gradle build itself, and does not need to take into * account the JDK version required by Gradle plugins (such as the * Android Gradle Plugin) */ kotlin { jvmToolchain 11 } /** * 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' } } /** * To override source and target compatibility (if different from the * tool chain JDK version), add the following. All of these * default to the same value as kotlin.jvmToolchain. If you're using the * same version for these values and kotlin.jvmToolchain, you can * remove these blocks. */ //compileOptions { // sourceCompatibility JavaVersion.VERSION_11 // targetCompatibility JavaVersion.VERSION_11 //} //kotlinOptions { // jvmTarget = '11' //} } /** * 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.7.0' implementation fileTree(dir: 'libs', include: ['*.jar']) }
Gradle プロパティ ファイル
Gradle には、ルート プロジェクト ディレクトリにプロパティ ファイルも 2 つあります。このファイルを使用することで、Gradle ビルド ツールキット自体の設定を指定できます。
-
gradle.properties
- Gradle デーモンの最大ヒープサイズなど、プロジェクト レベルの Gradle 設定を構成できます。詳細については、ビルド環境をご覧ください。
-
local.properties
- 以下の項目など、ビルドシステムのローカル環境プロパティを構成します。
ndk.dir
- NDK へのパス。このプロパティは非推奨になりました。ダウンロードしたバージョンの NDK はすべて、Android SDK ディレクトリ内のndk
ディレクトリにインストールされています。sdk.dir
- Android 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 は複数のマニフェストをマージする際も同じ優先順位を使用するため、最終マニフェストでビルド バリアントごとにさまざまなコンポーネントまたは権限を定義できます。カスタム ソースセットの作成について詳しくは、ソースセットの作成をご覧ください。
バージョン カタログ
ビルドに共通の依存関係を持つ複数のモジュールが含まれている場合や、共通の依存関係を持つ複数の独立したプロジェクトがある場合は、バージョン カタログまたは部品構成表(BOM)を使用して共通のバージョンを指定することをおすすめします。
他のビルドシステム
Bazel を使用して Android アプリを作成することは可能ですが、公式にはサポートされていません。Android Studio は公式には Bazel プロジェクトをサポートしていません。
Bazel を使用するビルドの現在の制限事項については、既知の問題をご覧ください。