サイトのトップへ戻る

Android Studio ドキュメント 日本語訳

サイト内検索

ビルド構成を設定する

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 アプリモジュールのビルドプロセス。

図 1で示すように、典型的なAndroid アプリモジュールのビルドプロセスは、以下のような一般的な手順に沿って行われます。:

  1. コンパイラーはソースコードをDEX (Dalvik Executable)ファイルに変換します。このDEX はAndroid 端末上で実行するバイトコードを含んでいます。 また、他のものは全てコンパイル済みリソースへ変換します。
  2. APK パッケージャーは、DEX ファイルとコンパイル済みリソースを一つのAPKに統合します。 ですが、アプリをAndroid上にインストールしてデプロイする前にAPK の署名を行わなければなりません。
  3. The APK パッケージャーはデバッグ用のキーストアやリリース用のキーストアを使ってAPKを署名します。:
    1. あなたがアプリをデバッグ版でビルドしている場合、すなわちテストやプロファイルのみを目的としたアプリの場合、パッケージャーはアプリをデバッグ用のキーストアで署名します。Android Studio はデバッグ用のキーストアを使って自動的に新しいプロジェクトの設定を行います。
    2. あなたがアプリを外部にリリースする目的のリリース版でビルドしている場合、パッケージャーはリリース用のキーストアを使ってアプリを署名します。 リリース用のキーストアを作成するには signing your app in Android Studioを参照してください。
  4. 最終的なAPKを生成する前に、パッケージャーは zipalign を使ってアプリを最適化し、端末上で実行する時に使用するメモリを減らすようにします。

ビルドプロセスが終わると、デバッグ用APKもしくはリリース用APKが作成され、デプロイやテストや外部ユーザーへのリリースができます。



ビルド設定のカスタム

Gradle と Android プラグインを使うと、ビルドにおける以下の面で役立ちます:

ビルドタイプ
ビルドタイプは、アプリのビルドとパッケージを行う時にGradleが使用する、特定のプロパティを定義します。 通常は、開発ライフサイクルの様々な段階に応じて異なる設定が行われます。 例えば、デバッグビルドタイプではデバッグオプションが有効になってデバッグキーでAPKを署名します。 一方リリースビルドタイプでは、コードの圧縮、難読化が行われ、配布用のリリースキーでAPKを署名します。 アプリをビルドするには、少なくとも一つのビルドタイプを定義しなければなりません。—Android Studio は既定ではデバッグビルドタイプとリリースビルドタイプを作成します。 アプリのパッケージング設定をカスタマイズするには、ビルドタイプを設定する方法を参照してください。
プロダクトフレーバー
プロダクトフレーバーとは、アプリの無料版や有料版といったような、ユーザーへリリースするアプリの異なるバージョンを表します。 全てのバージョンのアプリので共通して使用される部分は共有・再利用しつつ、プロダクトフレーバーをカスタマイズして異なるコードとリソースを使用することができます。 プロダクトフレーバーの使用は任意で、それらは手動で作成する必要があります。 異なるバージョンのアプリを作成するには、プロダクトフレーバーを設定する方法を参照してください。
ビルドバリアント
ビルドバリアントとは、ビルドタイプとプロダクトフレーバーをまたがったもので、アプリをビルドするためにGradleが使用する設定のことです。 ビルドバリアントを使用すると、開発中にデバッグ版のプロダクトフレーバーをビルドしたり、配布時にリリース版のプロダクトフレーバーを署名したりできます。 ビルドバリアントを直接設定することはありませんが、ビルドバリアントを構成するビルドタイプとプロダクトフレーバーは設定します。 追加のビルドタイプやプロダクトフレーバーを作成すると、追加のビルドバリアントも作成されます。 ビルドバリアントの作成や管理する方法を知りたいのであれば、ビルドバリアントを設定するの概要を参照してください。
マニフェストエントリー
ビルドバリアントの設定上から、マニフェストファイルのいくつかのプロパティを設定することができます。 これらのビルド値が、マニフェストファイルで既に設定されている値を上書きします。 これは、各apkファイルが異なるアプリケーション名・最小SDKバージョン・ターゲットSDKバージョンを持つモジュール用に、複数のAPKを生成したい場合に便利です。 複数のマニフェストが存在する場合、Gradle はマニフェスト設定を結合します
依存関係
ビルドシステムは、ローカルファイルシステムとリモートリポジトリーから、プロジェクトの依存関係を管理します。 これのおかげで、依存ファイルのバイナリパッケージをあなたが手動で検索してダウンロードしてプロジェクトディレクトリへコピーするといった手間が省けます。 詳細については、 依存関係を宣言するを参照してください。
署名
ビルドシステムを使用することで、ビルド構成で署名設定を指定できます。 また、ビルドシステムはビルドプロセス中に自動でAPKに署名を行うことができます。 ビルド時にパスワードが要求されるのを防ぐために、ビルドシステムは既定のキーと既知の資格情報を使った証明書でデバッグバージョンの署名を行います。 ビルドについて明示的に署名設定を定義しなければ、ビルドシステムはリリースバージョンに署名を行いません。 リリースキーがない場合、Sign Your Appで説明している手順でキーを生成できます。
ProGuard
ビルドシステムを使用することで、各ビルドバリアントごとに異なるProGuard ルールファイルを指定できます。ビルドプロセス中に、ビルドシステムはProGuard を実行してクラスの縮小と難読化を行うことができます。
APK Splits
ビルドシステムを使用することで、特定の画面密度やApplication Binary Interface (ABI)用のコードとリソースのみを含んだ別々のAPKを自動的にビルドすることができます。 詳細については APK スプリットを設定するを参照してください。


ビルド設定ファイル

カスタムビルド設定を作成するには、一つ以上のビルド設定ファイルや build.gradleファイルを変更する必要があります。 これらのプレーンテキストファイルでは、ドメイン固有言語(DSL) を使ってビルドロジックの記述と操作を行います。 これにはJava 仮想マシン(JVM)の動的言語であるGroovyが使われます。 Gradle 用Android プラグインが必要なDSL 要素のほとんどを取り込んでいるので、ビルド設定をする際にGroovy について知っておく必要はありません。 Android のDSLプラグインについてさらに知るには、 DSL のリファレンスドキュメントを参照してください。.

新規プロジェクトを作成した際、図 2で示すように、Android Studio はあなたに代わって、これらのファイルのいくつかを自動的に作成し、適切なデフォルトにも度付いてそれらを組み込みます。

図 2. Android アプリモジュールの既定プロジェクト構造。

Android アプリの標準的なプロジェクト構造の中には、いくつかGradle ビルド設定ファイルが存在します。 ビルド設定を行う前に、これら各ファイルの範囲と目的、定義すべき基本的DSL 要素を理解することが重要です。



Gradle の設定ファイル

プロジェクトのルートディレクトリに置かれている settings.gradle ファイルは、アプリをビルドする時にどのモジュールをインクルードするのかGradle に指示をします。 ほとんどのプロジェクトの場合、ファイルは単純で以下をインクルードしているだけです。:

include ‘:app’

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



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

プロジェクトのルートディレクトリに置かれているトップレベル build.gradle ファイルは、プロジェクトの全てのモジュールに適用するビルド設定を定義します。 既定では、トップレベルビルドファイルは buildscript{} ブロックを使って、プロジェクト内の全てのモジュールに共通する Gradle repositoriesdependencies を定義します。 以下のコード例では、新規プロジェクトを作成した直後のトップレベル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 ビルドツールキット自身の設定を指定することができます。:

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/<productFlavorBuildType>/
特定のビルドバリアントのみのコードとリソースを含めるには、このソースセットを作成します。

例えばアプリの "fullDebug" バージョンを生成する場合には、ビルドシステムは以下ソースセット群のコード、設定、リソースを全て使用します。:

  • src/fullDebug/ (ビルドバリアントのソースセット)
  • src/debug/ (ビルドタイプのソースセット)
  • src/full/ (プロダクトフレーバーのソースセット)
  • src/main/ (メインのソースセット)

メモ: Android StudioでメニューオプションFile > Newを使って新規にファイルやディレクトリを作成する場合、 それを特定のソースセット用に作成することができます。 選択できるソースセットはビルド設定によって変わります。 Android Studio は、ディレクトリが存在しない場合は自動的に必要なディレクトリを作成します。

別々のソースセットに同じファイルの異なるバージョンのものが含まれていた場合、 Gradleは使用するファイルを決める際に以下の優先順位で処理します。 (左にあるソースセットが右にあるソースセットより優先されます。):

ビルドバリアント > ビルドタイプ > プロダクトフレーバー > メインのソースセット > 依存関係のライブラリ

これにより、Gradle はビルドするビルドバリアント固有のファイルを使用しながら、他のバージョンのアプリと共通するアクティビティやアプリケーションロジックやリソースを使い回すことができます。 マニフェストファイルを結合する時にも Gradleはこれと同じ優先順位を使用するので、 各ビルドバリアントは最終マニフェストで異なるコンポーネントや権限を使用することができます。 カスタムソースセットの作成についてより学ぶには、ビルドバリアント用のソースセットを作成するを参照してください。