Android のビルドシステムは、アプリのリソースとソースコードをコンパイルし、それらをAPKファイルにパッケージ化します。 APKファイルを使ってテストやデプロイや署名や配信を行うことができます。 Android Studio は、高度なビルドツールキットのGradleを使ってビルドプロセスの自動化と管理を行っています。 また、これにより柔軟なカスタムビルド設定を定義することができます。 各ビルド設定は自身のコートとリソースのセットを定義することができ、アプリの全バージョンに共通する部分については再利用します。 Gradle用Androidプラグインはビルドツールキットを使って、Androidアプリケーションのビルドやテストに特化した処理と設定を行います。
Gradle と Android プラグインは Android Studioから独立して動作します。 つまり、 Android Studio上からだけではなく、コマンドライン上から、またAndroid Studio がインストールされていないマシーン(継続的インテグレーションサーバなど)のコマンドライン上からも Androidアプリのビルドを行うことができます。 Android Studioを使用していない場合は、 コマンドライン上からアプリのビルドと実行を行う方法について学ぶことができます。 ビルドの出力結果については、コマンドライン上からプロジェクトをビルドしても、リモートマシン上でビルドしても、Android Studioを使っても同じです。
メモ: Gradle と Android プラグインは Android Studioから独立して動作するため、ビルドツールは別個で更新する必要があります。 Gradle と Android プラグインを更新する方法について学ぶにはリリースノートを参照してください。
Android のビルドシステムの柔軟性のおかげで、アプリのコアソースファイルを編集しなくてもビルド設定のカスタムを行うことができます。 この項目では、Android のビルドシステムはどのように動作するのか、それにより複数のビルド設定のカスタムや自動化をどのように行えるか、について説明します。 単にアプリをデプロイする方法について知りたいのであれば、Building and Running from Android Studioを参照してください。 Android Studioを使ってすぐにカスタムビルド設定を作成するには、ビルドバリアントを設定するを参照してください。
ビルドプロセスでは多くのツールが動作し、プロジェクトをAndroid アプリケーションパッケージ (APK)に変換します。 ビルドプロセスは非常に柔軟性が高いので、内部で起こっていることを理解することは有益です。
図 1で示すように、典型的なAndroid アプリモジュールのビルドプロセスは、以下のような一般的な手順に沿って行われます。:
ビルドプロセスが終わると、デバッグ用APKもしくはリリース用APKが作成され、デプロイやテストや外部ユーザーへのリリースができます。
Gradle と Android プラグインを使うと、ビルドにおける以下の面で役立ちます:
カスタムビルド設定を作成するには、一つ以上のビルド設定ファイルや build.gradle
ファイルを変更する必要があります。
これらのプレーンテキストファイルでは、ドメイン固有言語(DSL) を使ってビルドロジックの記述と操作を行います。
これにはJava 仮想マシン(JVM)の動的言語であるGroovyが使われます。
Gradle 用Android プラグインが必要なDSL 要素のほとんどを取り込んでいるので、ビルド設定をする際にGroovy について知っておく必要はありません。
Android のDSLプラグインについてさらに知るには、 DSL のリファレンスドキュメントを参照してください。.
新規プロジェクトを作成した際、図 2で示すように、Android Studio はあなたに代わって、これらのファイルのいくつかを自動的に作成し、適切なデフォルトにも度付いてそれらを組み込みます。
Android アプリの標準的なプロジェクト構造の中には、いくつかGradle ビルド設定ファイルが存在します。 ビルド設定を行う前に、これら各ファイルの範囲と目的、定義すべき基本的DSL 要素を理解することが重要です。
プロジェクトのルートディレクトリに置かれている settings.gradle
ファイルは、アプリをビルドする時にどのモジュールをインクルードするのかGradle に指示をします。
ほとんどのプロジェクトの場合、ファイルは単純で以下をインクルードしているだけです。:
include ‘:app’
しかし、マルチモジュールプロジェクトの場合は最終ビルドに含める各モジュールを指定する必要があります。
プロジェクトのルートディレクトリに置かれているトップレベル build.gradle
ファイルは、プロジェクトの全てのモジュールに適用するビルド設定を定義します。
既定では、トップレベルビルドファイルは buildscript{}
ブロックを使って、プロジェクト内の全てのモジュールに共通する Gradle repositoriesとdependencies を定義します。
以下のコード例では、新規プロジェクトを作成した直後のトップレベルbuild.gradle
に記述されている、既定設定とDSL 要素です。
/** * The buildscript {} block is where you configure the repositories and * dependencies for Gradle itself--meaning, you should not include dependencies * for your modules here. For example, this block includes the Android plugin for * Gradle as a dependency because it provides the additional instructions Gradle * needs to build Android app modules. */ buildscript { /** * The repositories {} block configures the repositories Gradle uses to * search or download the 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 * JCenter as the repository Gradle should use to look for its dependencies. */ repositories { jcenter() } /** * The dependencies {} block configures the dependencies Gradle needs to use * to build your project. The following line adds Android Plugin for Gradle * version 2.2.0 as a classpath dependency. */ dependencies { classpath 'com.android.tools.build:gradle:2.2.0' } } /** * The allprojects {} block is where you configure the repositories and * dependencies used by all modules in your project, such as third-party plugins * or libraries. Dependencies that are not required by all the modules in the * project should be configured in module-level build.gradle files. For new * projects, Android Studio configures JCenter as the default repository, but it * does not configure any dependencies. */ allprojects { repositories { jcenter() } }
各<project>/<module>/
ディレクトリ内に置かれているモジュールレベル build.gradle
ファイルを使って、ディレクトリ内に置かれている特定のモジュール用のビルド設定を行うことができます。
これらのビルド設定を行うことで、追加のビルドタイプやプロダクトフレーバーのようなカスタムパッケージオプションを用意したり、main/
アプリのマニファストやトップレベルbuild.gradle
ファイルの設定を上書きしたりできます。
以下 Android アプリモジュールの build.gradle
ファイル例では、
知っておくべき基本的なDSL 要素と設定のいくつかの概要を記載しています。
/** * 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. */ apply plugin: 'com.android.application' /** * The android {} block is where you configure all your Android-specific * build options. */ android { /** * 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. * * 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. */ compileSdkVersion 25 buildToolsVersion "25.0.0" /** * 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 { /** * applicationId uniquely identifies the package for publishing. * However, your source code should still reference the package name * defined by the package attribute in the main/AndroidManifest.xml file. */ 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 25 // 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 Proguard settings 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 defaultConfig {} 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. */ productFlavors { free { applicationId 'com.example.myapp.free' } paid { applicationId 'com.example.myapp.paid' } } /** * The splits {} block is where you can configure different APK builds that * each contain only code and resources for a supported screen density or * ABI. You'll also need to configure your build so that each APK has a * different versionCode. */ splits { // Screen density split settings density { // Enable or disable the density split mechanism enable false // Exclude these densities from splits exclude "ldpi", "tvdpi", "xxxhdpi", "400dpi", "560dpi" } } } /** * The dependencies {} block in the module-level build configuration file * only specifies dependencies required to build the module itself. */ dependencies { compile project(":lib") compile 'com.android.support:appcompat-v7:25.0.1' compile fileTree(dir: 'libs', include: ['*.jar']) }
Gradle はプロジェクトのルートディレクトリに置かれている二つのプロパティファイルもインクルードします。 このプロパティファイルを使ってGradle ビルドツールキット自身の設定を指定することができます。:
gradle.properties
local.properties
プロジェクトのビルド設定ファイルを変更した場合、 Android Studioがビルド設定をインポートして設定でビルドエラーが発生しないか確認できるようにするため、 プロジェクトファイルを同期する必要があります。
プロジェクトファイルを同期するには、図 3で示しているように、設定ファイルを変更すると通知バー上に表示される Sync Now をクリックするか、
メニューバーからSync Project をクリックします。
Android Studioが設定のエラーを通知したとします。
例えば、 compileSdkVersion
よりも新しいバージョンのAPIでしか使えないAPI 機能をソースコードで使用した場合など。
その場合、Messages ウィンドウが表示されてその問題について説明します。
Android Studioは、ソースコードと各モジュールのリソースを、論理的なソースセットとしてグループ分けします。
モジュールのmain/
ソースセットには、それの全てのビルドバリアントで使用されるコードとリソースが含まれています。
他のソースセットに関しては、作成は任意です。
新たにビルドバリアントを設定しても Android Studio はそれらのソースセットを自動的に作成することはありません。
しかし、main/
と同様にソースセットを作成することで、特定のバージョンのアプリをビルドする際のみGradle が使用するファイルとリソースを整理することができます。:
src/main/
src/<buildType>/
src/<productFlavor>/
src/<productFlavorBuildType>/
例えばアプリの "fullDebug" バージョンを生成する場合には、ビルドシステムは以下ソースセット群のコード、設定、リソースを全て使用します。:
src/fullDebug/
(ビルドバリアントのソースセット)
src/debug/
(ビルドタイプのソースセット)
src/full/
(プロダクトフレーバーのソースセット)
src/main/
(メインのソースセット)
メモ: Android StudioでメニューオプションFile > Newを使って新規にファイルやディレクトリを作成する場合、 それを特定のソースセット用に作成することができます。 選択できるソースセットはビルド設定によって変わります。 Android Studio は、ディレクトリが存在しない場合は自動的に必要なディレクトリを作成します。
別々のソースセットに同じファイルの異なるバージョンのものが含まれていた場合、 Gradleは使用するファイルを決める際に以下の優先順位で処理します。 (左にあるソースセットが右にあるソースセットより優先されます。):
ビルドバリアント > ビルドタイプ > プロダクトフレーバー > メインのソースセット > 依存関係のライブラリ
これにより、Gradle はビルドするビルドバリアント固有のファイルを使用しながら、他のバージョンのアプリと共通するアクティビティやアプリケーションロジックやリソースを使い回すことができます。 マニフェストファイルを結合する時にも Gradleはこれと同じ優先順位を使用するので、 各ビルドバリアントは最終マニフェストで異なるコンポーネントや権限を使用することができます。 カスタムソースセットの作成についてより学ぶには、ビルドバリアント用のソースセットを作成するを参照してください。