ビルドの設定

Android ビルドシステムはアプリリソースとソースコードをコンパイルして、テスト、デプロイ、署名、および配布が可能な APK にパッケージ化します。 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 アプリケーション パッケージ(APK)に変換する多くのツールとプロセスが含まれます。 ビルドプロセスは非常に柔軟であるため、内部でどのような処理が実行されるのかを理解することは有用です。

図 1 一般的な Android アプリ モジュールのビルドプロセス。

図 1 に示されている一般的な Android アプリ モジュールのビルドプロセスでは、通常、次のようなステップが実行されます。

  1. コンパイラーにより、ソースコードは DEX (Dalvik Executable)ファイルに変換されます。このファイルには、Android 端末で実行されるバイトコードが含まれます。その他すべてはコンパイルされたリソースに変換されます。
  2. APK Packager は、DEX ファイルとコンパイルされたリソースを単一の APK にまとめます。 ただし、アプリを Android 端末にインストールおよびデプロイする前に、APK に署名する必要があります。
  3. APK Packager はデバッグまたはリリース キーストアを使用して、APK に署名します。
    1. デバッグ バージョンのアプリ(つまり、テストとプロファイリング専用のアプリ)をビルドする場合、Packager はデバッグ キーストアでアプリに署名します。 Android Studio はデバッグ キーストアを用いて新しいプロジェクトを自動的に設定します。
    2. リリース バージョンのアプリ(一般公開用)をビルドする場合、Packager はリリース キーストアでアプリに署名します。 リリース キーストアを作成するには、Android Studio でアプリに署名するをお読みください。
  4. 最終 APK を生成する前に、Packager は zipalign ツールを使用して、アプリを最適化することにより、アプリが端末で実行されるときのメモリの使用量を削減します。

ビルドプロセスの最後に生成されるアプリのデバッグ APK またはリリース APK を使用して、デプロイ、テスト、または外部ユーザーへのリリースを行うことができます。

カスタムビルドの設定

Gradle と Android プラグインは、ビルドの次の要素の設定を支援します。

ビルドタイプ
ビルドタイプは、アプリをビルドしてパッケージ化するときに Gradle が使用する特定のプロパティを定義します。通常、ビルドタイプは、開発ライフサイクルのさまざまな段階で設定されます。 たとえば、デバッグ ビルドタイプでは、デバッグ オプションが有効化され、デバッグキーで APK に署名します。リリース ビルドタイプでは、圧縮や難読化が実行され、配布するためにリリースキーで APK に署名します。 アプリをビルドするには、少なくとも 1 つのビルドタイプを定義する必要があります。Android Studio はデフォルトでデバッグおよびリリース ビルドタイプを作成します。 アプリのパッケージ設定のカスタマイズを開始するには、ビルドタイプを設定する方法について学習してください。
プロダクト フレーバー
プロダクト フレーバーは、無料版や有料版のアプリなど、ユーザーにリリースするさまざまなバージョンのアプリを表します。 プロダクト フレーバーをカスタマイズして、さまざまなコードやリソースを使用するとともに、アプリのすべてのバージョンに共通の部分を共有および再利用することができます。 プロダクト フレーバーはオプションであり、手動で作成する必要があります。 さまざまなバージョンのアプリの作成を開始するには、プロダクト フレーバーを設定する方法について学習してください。
ビルド バリアント
ビルド バリアントはビルドタイプとプロダクト フレーバーを組み合わせたもので、Gradle がアプリをビルドするために使用する設定です。 ビルド バリアントを使用して、開発時にプロダクト フレーバーのデバッグ バージョンをビルドしたり、配布用のプロダクト フレーバーの署名済みリリース バージョンをビルドしたりできます。 ビルド バリアントを直接設定するのではなく、ビルド バリアントを形成するビルドタイプとプロダクト フレーバーを設定します。 追加のビルドタイプやプロダクト フレーバーを作成すると、さらに多くのビルド バリアントが作成されます。 ビルド バリアントを作成して管理する方法について学習するには、ビルド バリアントの設定 の概要をお読みください。
マニフェスト エントリ
ビルド バリアントの設定でマニフェスト ファイルの一部のプロパティの値を指定することができます。 これらのビルド値により、マニフェスト ファイルの既存の値がオーバーライドされます。 このオーバーライドは、複数のモジュールの複数の APK を生成し、各 APK ファイルに、それぞれ異なるアプリ名、SDK の最小バージョン、SDK のターゲット バージョンを持たせたい場合に便利です。 複数のマニフェストが存在する場合、Gradle はマニフェストの設定を統合します。
依存関係
ビルドシステムは、ローカル ファイルシステムおよびリモート リポジトリからプロジェクトの依存関係を管理します。 これにより、依存関係のバイナリ パッケージを手動で検索してダウンロードし、プロジェクト ディレクトリにコピーする必要がなくなります。 詳細については、ビルドの依存関係の追加をご覧ください。
署名
ビルドシステムを使用すると、ビルド設定で署名設定を指定し、ビルドプロセス中に APK に自動的に署名することができます。 ビルドシステムでは、既知の認証情報を使用してデフォルトのキーと証明書でデバッグ バージョンに署名し、ビルド時のパスワード プロンプトが出ないようにします。 また、このビルドの署名設定を明示的に定義していない限り、リリース バージョンは署名されません。 リリースキーがない場合は、アプリに署名するの説明に従ってリリースキーを作成することができます。
ProGuard
ビルドシステムを使用すると、各ビルド バリアントに対してさまざまな ProGuard ルールファイルを指定することができます。 ビルドシステムでは、ビルドプロセス中に ProGuard を実行して、クラスを圧縮および難読化することができます。
複数 APK のサポート
ビルドシステムを使用すると、特定の画面密度やアプリケーション バイナリ インターフェース(ABI)に必要なコードとリソースのみが含まれるさまざまな APK を自動的にビルドすることができます。 詳細については、 複数の APK のビルドをご覧ください。

ビルド設定ファイル

カスタムビルド設定を作成するには、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 に通知されます。 大部分のプロジェクトでは、このファイルはシンプルであり、以下のものだけが含まれています。

include ‘:app’

ただし、マルチモジュールのプロジェクトでは、最終ビルドに含める必要のある各モジュールを指定する必要があります。

トップレベルのビルドファイル

ルート プロジェクト ディレクトリにあるトップレベルの build.gradle ファイルにより、プロジェクトのすべてのモジュールに適用されるビルド設定が定義されます。 デフォルトでは、このトップレベルのビルドファイルは buildscript ブロックを使用して、プロジェクトのすべてのモジュールに共通の Gradle リポジトリ依存関係を定義します。 次のコードサンプルは、新しいプロジェクトを作成した後、トップレベルの 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.
     *
     * New projects created using Android Studio 3.0 and higher also include
     * Google's Maven repository.
     */

    repositories {
        google()
        jcenter()
    }

    /**
     * The dependencies block configures the dependencies Gradle needs to use
     * to build your project. The following line adds Android plugin for Gradle
     * version 3.4.1 as a classpath dependency.
     */

    dependencies {
        classpath 'com.android.tools.build:gradle:3.4.1'
    }
}

/**
 * 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. However, you should configure module-specific dependencies in
 * each module-level build.gradle file. For new projects, Android Studio
 * includes JCenter and Google's Maven repository by default, but it does not
 * configure any dependencies (unless you select a template that requires some).
 */

allprojects {
   repositories {
       google()
       jcenter()
   }
}

プロジェクト全体のプロパティ設定

複数のモジュールを含む Android プロジェクトでは、プロジェクト レベルで特定のプロパティを定義して、それをすべてのモジュールで共有すると便利かもしれません。 そのためには、追加のプロパティを、トップレベルの build.gradle ファイル内の ext ブロックに追加します。

buildscript {...}

allprojects {...}

// This block encapsulates custom properties and makes them available to all
// modules in the project.
ext {
    // The following are only a few examples of the types of properties you can define.
    compileSdkVersion = 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"
    ...
}
...

同じプロジェクトのモジュールからこれらのプロパティにアクセスするには、モジュールの build.gradle ファイル(このファイルについては次のセクションで説明します)で次の構文を使用します。

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}"
    ...
}

注: Gradle では、モジュール レベルでプロジェクト全体のプロパティを定義することもできますが、その場合、プロパティを共有するモジュールが結合されるため、避けてください。 モジュールが結合すると、後でスタンドアロンのプロジェクトとしてモジュールをエクスポートするのが困難になり、Gradle が並行プロジェクト実行を使用して複数モジュールのビルドを高速に行うことが実質的にできなくなります。

モジュール レベルのビルドファイル

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.
   */

  compileSdkVersion 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 "28.0.3"

  /**
   * 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 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 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 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 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 {
    // Settings to build multiple APKs based on screen density.
    density {

      // Enable or disable building multiple APKs.
      enable false

      // Exclude these densities when building multiple APKs.
      exclude "ldpi", "tvdpi", "xxxhdpi", "400dpi", "560dpi"
    }
  }
}

/**
 * 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'])
}

Gradle プロパティ ファイル

Gradle では、ルート プロジェクト ディレクトリに 2 つのプロパティ ファイルも含まれています。これらのファイルを使用して、Gradle ビルド ツールキットの設定を指定することができます。

gradle.properties
ここで、Gradle デーモンの最大ヒープサイズなど、プロジェクト全体にわたる Gradle 設定を指定できます。 詳細については、ビルド環境をご覧ください。
local.properties
SDK インストールへのパスなど、ビルドシステムのローカル環境プロパティを設定します。 このファイルのコンテンツは、Android Studio によって自動的に生成され、ローカルのデベロッパー環境に固有のものであるため、このファイルを手動で変更したり、バージョン管理システムでチェックしたりしないでください。

プロジェクトと 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 は同じ優先順位を使用するため、各ビルド バリアントにより、最終マニフェストのさまざまなコンポーネントやパーミッションを定義できます。 カスタム ソースセットの作成に関する詳細については、ビルド バリアントのソースセットの作成をご覧ください。