Skip to content

Most visited

Recently visited

navigation

ビルドの設定

動画

新しい Android SDK ビルドシステム

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 ファイルのアプリ名、SDK の最小バージョン、または SDK のターゲット バージョンが異なる複数のモジュールに対して複数の APK を生成する場合に便利です。複数のマニフェストが存在する場合、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 のリファレンス ドキュメントをご覧ください。

新しいプロジェクトを開始すると、Android Studio は、図 2 に示されているいくつかのファイルを自動的に作成し、適切なデフォルト値に基づいて、これらのファイルを設定します。

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

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

たとえば、"fullDebug" バージョンのアプリを生成する場合、ビルドシステムは、次のソースセットのコード、設定、およびリソースを統合します。

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

異なるソースセットに異なるバージョンの同じファイルが含まれている場合、Gradle は使用するファイルを決定するときに次の優先順位を使用します(左側のソースセットが右側のソースセットのファイルと設定をオーバーライドします)。

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

これにより、Gradle で、ビルドするビルド バリアント固有のファイルを使用しながら、アプリの他のバージョンと共通のアクティビティ、アプリロジック、およびリソースを再利用できるようになります。複数のマニフェストをマージするときに、Gradle は同じ優先順位を使用するため、各ビルド バリアントにより、最終マニフェストでさまざまなコンポーネントやパーミッションを定義できます。カスタム ソースセットの作成に関する詳細については、ビルド バリアントのソースセットの作成をご覧ください。

This site uses cookies to store your preferences for site-specific language and display options.

Hooray!

This class requires API level or higher

This doc is hidden because your selected API level for the documentation is . You can change the documentation API level with the selector above the left navigation.

For more information about specifying the API level your app requires, read Supporting Different Platform Versions.

Take a one-minute survey?
Help us improve Android tools and documentation.