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 プラグインはビルドプロセスの大部分を行いますが、ビルドプロセスの特定の側面を理解し、要件に合わ��てビルドを調整できるようにすると便利です。
プロジェクトによってビルド目標が異なる場合があります。たとえば、サードパーティ ライブラリのビルドでは、Android Archive(AAR)ライブラリまたは Java Archive(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 を使用する必要があります。
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 はこれらのファイルの一部を自動的に作成し、適切なデフォルト値に基づいて、ファイルを設定します。プロジェクト ファイル構造は、次のレイアウトになります。
└── MyApp/ # Project ├── gradle/ │ └── wrapper/ │ └── gradle-wrapper.properties ├── build.gradle(.kts) ├── settings.gradle(.kts) └── app/ # Module │ ├── build.gradle(.kts) │ ├── build/ │ ├── libs/ │ └── src/ │ └── main/ # Source set │ ├── java/ │ │ └── com.example.myapp │ ├── res/ │ │ ├── drawable/ │ │ ├── values/ │ │ └── ... │ └── AndroidManifest.xml
Android アプリの標準プロジェクト構造には、数種類の Gradle ビルド構成ファイルが含まれています。ビルドの構成を開始する前に、各ファイルのスコープと目的、定義する基本的な DSL 要素を理解することが重要です。
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. 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")
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'
トップレベル ビルドファイル
最上位の 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.5.0" apply false id("com.android.library") version "8.5.0" apply false id("org.jetbrains.kotlin.android") version "1.9.23" 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.5.0' apply false id 'com.android.library' version '8.5.0' apply false id 'org.jetbrains.kotlin.android' version '1.9.23' apply false }