ビルドバリアントの設定

このドキュメントはビルドの設定の概要を元に構成されており、ビルドバリアントを設定して、単一のプロジェクトからさまざまなバージョンのアプリを作成する方法と、依存関係と署名設定を適切に管理する方法について説明しています。

各ビルドバリアントは、ビルド可能なさまざまなバージョンのアプリを表しています。たとえば、コンテンツが制限された無料版のアプリと多くのコンテンツが含まれた有料版のアプリを作成することができます。また、API レベルまたは他の端末のバリエーションに基づいて、異なる端末を対象とするさまざまなバージョンのアプリをビルドすることができます。ただし、端末の ABI または画面密度に基づいてさまざまなバージョンをビルドする場合は、APK の分割を使用します。

ビルドバリアントは、Gradle で特定のルールセットを使用して、ビルドタイプとプロダクトフレーバー内に構成されている設定、コード、およびリソースを組み合わせた結果です。ビルドバリアントを直接設定するのではなく、ビルドバリアントを形成するビルドタイプとプロダクトフレーバーを設定します。

たとえば、"demo" プロダクトフレーバーでは、カスタムソースコード、リソース、最低限の API レベルなど、さまざまな機能と端末要件を指定することができます。また、"debug" ビルドタイプでは、デバッグオプションや署名キーなど、さまざまなビルドとパッケージの設定を適用します。これらを組み合わせたビルドバリアントがアプリの "demoDebug" バージョンになります。このバージョンには、"demo" プロダクトフレーバー、"debug" ビルドタイプ、および main/ ソースセットに含まれる設定とリソースを組み合わせたものが含まれます。

ビルドタイプの設定

モジュールレベルの build.gradle ファイルの android {} ブロック内で、ビルドタイプを作成して設定することができます。新しいモジュールを作成するときは、Android Studio によって、デバッグおよびリリースビルドタイプが自動的に作成されます。デバッグビルドタイプはビルド設定ファイルには指定されていませんが、Android Studio では debuggable true に設定します。これにより、安全な Android 端末でアプリをデバッグし、汎用デバッグキーストアで APK 署名を設定できるようになります。

特定の設定を追加または変更する場合、デバッグビルドタイプを設定に追加することができます。次のサンプルでは、デバッグビルドタイプ向けに applicationIdSuffix を指定し、デバッグビルドタイプの設定を使用して初期化される "jnidebug" ビルドタイプを設定しています。

android {
    ...
    defaultConfig {...}
    buildTypes {
        release {
            minifyEnabled true
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        }

        debug {
            applicationIdSuffix ".debug"
        }

        /**
         * The 'initWith' property allows you to copy configurations from other build types,
         * so you don't have to configure one from the beginning. You can then configure
         * just the settings you want to change. The following line initializes
         * 'jnidebug' using the debug build type, and changes only the
         * applicationIdSuffix and versionNameSuffix settings.
         */

        jnidebug {

            // This copies the debuggable attribute and debug signing configurations.
            initWith debug

            applicationIdSuffix ".jnidebug"
            jniDebuggable true
        }
    }
}

注: ビルド設定ファイルに変更を加えると、Android Studio では、新しい設定のプロジェクトを同期するように求められます。プロジェクトを同期するには、変更を加えた直後に通知バーに表示される [Sync Now] をクリックするか、ツールバーの [Sync Project] をクリックします。 Android Studio が設定のエラーを通知する場合は、問題の説明が記載された [Messages] ウィンドウが表示されます。

ビルドタイプで設定できるすべてのプロパティの詳細については、ビルドタイプの DSL リファレンスをご覧ください。

プロダクトフレーバーの設定

プロダクトフレーバーの作成方法はビルドタイプと同様で、productFlavors {} ブロックにプロダクトフレーバーを追加して必要な設定をします。プロダクトフレーバーでは、defaultConfig と同じプロパティがサポートされます。これは、defaultConfig が実際に ProductFlavor クラスに属しているためです。つまり、defaultConfig {} ブロックですべてのフレーバー向けの基本設定を指定して、その既定値（applicationId など）を各フレーバーで変更することができます。アプリケーション ID の詳細については、アプリケーション ID の設定をご覧ください。

注: パッケージ名は、main/ マニフェストファイルの package 属性を使用して指定する必要があります。また、ソースコードでそのパッケージ名を使用して、R クラスを参照したり、関連するアクティビティやサービスの登録を解決する必要があります。これにより、ソースコードを変更することなく、applicationId を使用して、パッケージ化および配布用の一意の ID を各プロダクトフレーバーに提供できるようになります。

次のコードサンプルでは、独自の applicationIdSuffix と versionNameSuffix を提供する "demo" および "full" プロダクトフレーバーを作成しています。

android {
    ...
    defaultConfig {...}
    buildTypes {...}
    productFlavors {
        demo {
            applicationIdSuffix ".demo"
            versionNameSuffix "-demo"
        }
        full {
            applicationIdSuffix ".full"
            versionNameSuffix "-full"
        }
    }
}

注: Google Play で複数 APK のサポートを利用してアプリを配布するには、すべてのバリアントに同じ値の applicationId を割り当て、各バリアントに異なる versionCode を付与します。Google Play でさまざまなバリアントのアプリを個別のアプリとして配布するには、各バリアントに異なる applicationId を割り当てる必要があります。

プロダクトフレーバーを作成して設定した後、通知バーで [Sync Now] をクリックします。同期が完了すると、Gradle はビルドタイプとプロダクトフレーバーに基づいてビルドバリアントを自動的に作成し、ビルドバリアントに <product-flavor><Build-Type> の形式で名前を付けます。たとえば、"demo" および "full" プロダクトフレーバーを作成し、ビルドタイプをデフォルトの "debug'" および "release" のままにした場合、Gradle は次のビルドバリアントを作成します。

demoDebug
demoRelease
fullDebug
fullRelease

ビルドして実行するビルドバリアントを、この中のいずれかに変更することができます。変更するには、[Build] > [Select Build Variant] に移動し、プルダウンメニューからビルドバリアントを選択します。独自の機能とリソースで各ビルドバリアントをカスタマイズするには、ソースセットを作成および管理する方法を把握しておく必要があります。

複数のプロダクトフレーバーの組み合わせ

複数のプロダクトフレーバーの設定を組み合わせる必要がある場合があります。たとえば、API レベルに応じて "full" と "demo" のプロダクトフレーバーに対して異なる設定を作成する必要がある場合などです。これを行うには、Gradle の Android プラグインで、フレーバーディメンションと呼ばれるプロダクトフレーバーのグループを作成します。アプリをビルドするときに、Gradle は定義された各フレーバーディメンションに含まれるプロダクトフレーバー設定を組み合わせ、さらにビルドタイプ設定を使用して、最終的なビルドバリアントを作成します。Gradle では、同じフレーバーディメンションに属するプロダクトフレーバーが組み合わされることはありません。

ヒント: ABI および画面密度に応じて異なるバージョンのアプリを作成する場合、プロダクトフレーバーを使うのではなく、APK の分割を設定する必要があります。

次のコードサンプルでは、flavorDimensions プロパティを使用して "mode" フレーバーディメンションを作成し、"full" と "demo" プロダクトフレーバーをグループ化しています。さらに、"api" フレーバーディメンションを作成して、API レベルに応じたプロダクトフレーバー設定をグループ化しています。

android {
  ...
  buildTypes {
    debug {...}
    release {...}
  }

  // Specifies the flavor dimensions you want to use. The order in which you
  // list each dimension determines its priority, from highest to lowest,
  // when Gradle merges variant sources and configurations. You must assign
  // each product flavor you configure to one of the flavor dimensions.
  flavorDimensions "api", "mode"

  productFlavors {
    demo {
      // Assigns this product flavor to the "mode" flavor dimension.
      dimension "mode"
      ...
    }

    full {
      dimension "mode"
      ...
    }

    // Configurations in the "api" product flavors override those in "mode"
    // flavors and the defaultConfig {} block. Gradle determines the priority
    // between flavor dimensions based on the order in which they appear next
    // to the flavorDimensions property above--the first dimension has a higher
    // priority than the second, and so on.
    minApi24 {
      dimension "api"
      minSdkVersion '24'
      // To ensure the target device receives the version of the app with
      // the highest compatible API level, assign version codes in increasing
      // value with API level. To learn more about assigning version codes to
      // support app updates and uploading to Google Play, read Multiple APK Support
      versionCode 30000 + android.defaultConfig.versionCode
      versionNameSuffix "-minApi24"
      ...
    }

    minApi23 {
      dimension "api"
      minSdkVersion '23'
      versionCode 20000  + android.defaultConfig.versionCode
      versionNameSuffix "-minApi23"
      ...
    }

    minApi21 {
      dimension "api"
      minSdkVersion '21'
      versionCode 10000  + android.defaultConfig.versionCode
      versionNameSuffix "-minApi21"
      ...
    }
  }
}
...

Gradle で作成されるビルドバリアントの数は、各フレーバーディメンション内のフレーバーの数と設定したビルドタイプをすべて乗算した数となります。Gradle で各ビルドバリアントまたは対応する APK に名前を付けるときは、最初に優先度の高いフレーバーディメンションに属するプロダクトフレーバー、次に優先度の低いディメンションのプロダクトフレーバー、最後にビルドタイプの順で並べた名前が付けられます。上記の例のようにビルド設定を使用すると、Gradle は次の命名スキームに従って合計 12 個のビルドバリアントを作成します。

ビルドバリアント: [minApi24, minApi23, minApi21][Demo, Full][Debug, Release]; 対応する APK: app-[minApi24, minApi23, minApi21]-[demo, full]-[debug, release].apk
たとえば、: ビルドバリアント: minApi24DemoDebug; 対応する APK: app-minApi24-demo-debug.apk

個別のプロダクトフレーバーおよびビルドバリアント用にソースセットディレクトリを作成することに加えて、プロダクトフレーバーの各組み合わせに対してもソースセットディレクトリを作成することが可能です。たとえば、Java ソースを作成して src/demoMinApi24/java/ ディレクトリに追加できます。この場合、Gradle ではこれらの 2 つのプロダクトフレーバーを組み合わせバリアントのビルド時のみ、これらのソースを使用します。プロダクトフレーバーの組み合わせに対して作成したソースセットは、個別の各プロダクトフレーバーに属するソースセットより優先されます。ソースセットの詳細および Gradle でリソースを統合する仕組みについては、ソースセットの作成をご覧ください。

バリアントのフィルタリング

Gradle は、設定されたプロダクトフレーバーとビルドタイプのすべての可能な組み合わせでビルドバリアントを作成します。ただし、その中には不要なビルドバリアントや、対象とするプロジェクトにおいては意味を持たないビルドバリアントも存在する場合があります。そのような特定のビルドバリアント設定を削除するには、モジュールレベルの build.gradle ファイル内にバリアントフィルタを作成します。

例として前のセクションのビルド設定を使用し、アプリのデモバージョンでは API レベル 23 以上のみをサポートすると仮定します。variantFilter {} ブロックを使用すると、"minApi21" と "demo" プロダクトフレーバーを組み合わせたすべてのビルドバリアント設定をフィルタで除外できます。

android {
  ...
  buildTypes {...}

  flavorDimensions "api", "mode"
  productFlavors {
    demo {...}
    full {...}
    minApi24 {...}
    minApi23 {...}
    minApi21 {...}
  }

  variantFilter { variant ->
      def names = variant.flavors*.name
      // To check for a certain build type, use variant.buildType.name == "<buildType>"
      if (names.contains("minApi21") && names.contains("demo")) {
          // Gradle ignores any variants that satisfy the conditions above.
          setIgnore(true)
      }
  }
}
...

ビルド設定にバリアントフィルタを追加して、通知バーで [Sync Now] をクリックすると、Gradle は指定された条件に一致するすべてのビルドバリアントを無視しします。そのため、メニューバーの [Build] > [Select Build Variant]（またはツールウィンドウバーの [Build Variants]）をクリックしたときに、ドロップダウンメニューにこれらのビルドバリアントが表示されなくなります。

ソースセットの作成

Android Studio はデフォルトで、すべてのビルドバリアントで共有するあらゆるファイル用に main/ ソースセットとディレクトリを作成します。一方、新しいソースセットを作成して、特定のビルドタイプ、プロダクトフレーバー（およびフレーバーディメンションを使用している場合はプロダクトフレーバーの組み合わせ）、ビルドバリアントごとに、Gradle でコンパイルおよびパッケージ化するファイルを厳密に管理することもできます。たとえば、main/ ソースセットで基本的な機能を定義しておき、プロダクトフレーバーのソースセットでクライアントごとにアプリのブランディングを変えたり、デバッグビルドタイプを使用するビルドバリアントのみを対象にして、特別なパーミッションやログ機能を含めたりすることができます。

Gradle では、main/ ソースセットと同様の構成で、他のソースセットファイルとディレクトリを管理する必要があります。たとえば、"debug" ビルドタイプ固有の Java クラスファイルは src/debug/java/ ディレクトリに配置しなければなりません。

Android Plugin for Gradle では、各ビルドタイプ、プロダクトフレーバー、ビルドバリアントに応じたファイル構成を表示する便利な Gradle 機能が提供されています。たとえば、以下のレポートのセクションは、Gradle で "debug" ビルドタイプの特定のファイルがあると予想される場所を示しています。

------------------------------------------------------------
Project :app
------------------------------------------------------------

...

debug
----
Compile configuration: compile
build.gradle name: android.sourceSets.debug
Java sources: [app/src/debug/java]
Manifest file: app/src/debug/AndroidManifest.xml
Android resources: [app/src/debug/res]
Assets: [app/src/debug/assets]
AIDL sources: [app/src/debug/aidl]
RenderScript sources: [app/src/debug/rs]
JNI sources: [app/src/debug/jni]
JNI libraries: [app/src/debug/jniLibs]
Java-style resources: [app/src/debug/resources]

ビルドの設定のために、このレポートを生成して表示するには、次の手順を実行します。

IDE ウィンドウの右側にある [Gradle] をクリックします。
[MyApplication] > [Tasks] > [android] に移動し、[sourceSets] をダブルクリックします。
レポートを表示するには、IDE ウィンドウの下部にある [Gradle Console] をクリックします。

注: レポートには、test/ および androidTest/ テストソースセットなど、アプリのテストを実行するために必要なファイルのソースセットを管理する方法も示されています。

新しいビルドバリアントを作成したとき、Android Studio では、ソースセットディレクトリは作成されませんが、便利なオプションがいくつか提供されます。たとえば、"debug" ビルドタイプ用に java/ ディレクトリのみを作成するには、次の手順を実行します。

[Project] ペインを開き、ペインの上部にあるプルダウンメニューから [Project] ビューを選択します。
MyProject/app/src/ に移動します。
src ディレクトリを右クリックし、[New] > [Folder] > [Java Folder] を選択します。
[Target Source Set] の横にあるプルダウンメニューから [debug] を選択します。
[Finish] をクリックします。

Android Studio ではデバッグビルドタイプ用のソースセットディレクトリを作成してから、そのディレクトリ内に java/ ディレクトリを作成します。または、特定のビルドバリアント用の新しいファイルをプロジェクトに追加する際に、Android Studio によってディレクトリが作成されるようにすることもできます。たとえば、"debug" ビルドタイプ用の values XML ファイルを作成するには、次の手順を実行します。

同じ [Project] ペインで、src ディレクトリを右クリックし、[New] > [XML] > [Values XML File] を選択します。
XML ファイルの名前を入力するか、デフォルトの名前のままにします。
[Target Source Set] の横にあるプルダウンメニューから [debug] を選択します。
[Finish] をクリックします。

"debug" ビルドタイプがターゲットソースセットとして指定されているため、Android Studio は XML ファイルを作成するときに、必要なディレクトリを自動的に作成します。生成されたディレクトリ構造は図 2 のようになります。

図 2 debug ビルドタイプの新しいソースセットディレクトリ。

これと同じ手順で、src/demo/ などのプロダクトフレーバー用のソースセットディレクトリや、src/demoDebug/ などのビルドバリアント用のソースセットディレクトリを作成することができます。また、src/androidTestDemoDebug/ のように特定のビルドバリアントを対象とするテストソースセットも作成できます。詳細については、テストソースセットをご覧ください。

デフォルトソースセット設定の変更

上述のソースセットの作成のセクションでは Gradle で想定する既定のソースセットファイル構成について説明しましたが、ソースファイルがその構成になってない場合は、sourceSets {} ブロックを使用して、Gradle でソースセットの各コンポーネントのファイルを収集するために確認する場所を変更できます。ファイルの場所を変更する必要はなく、モジュールレベルの build.gradle ファイルからの相対パスを指定するだけです。その場所で、Gradle は各ソースセットコンポーネントのファイルを見つけることができます。設定可能なコンポーネントや、それらを複数のファイルおよびディレクトリにマッピングできるどうかについては、Gradle DSL 向けの Android プラグインリファレンスをご確認ください。

次のコードサンプルでは、app/other/ ディレクトリのソースを main ソースセットの特定のコンポーネントにマッピングして、androidTest ソースセットのルートディレクトリを変更しています。

android {
  ...
  sourceSets {
    // Encapsulates configurations for the main source set.
    main {
      // Changes the directory for Java sources. The default directory is
      // 'src/main/java'.
      java.srcDirs = ['other/java']

      // If you list multiple directories, Gradle uses all of them to collect
      // sources. Because Gradle gives these directories equal priority, if
      // you define the same resource in more than one directory, you get an
      // error when merging resources. The default directory is 'src/main/res'.
      res.srcDirs = ['other/res1', 'other/res2']

      // Note: You should avoid specifying a directory which is a parent to one
      // or more other directories you specify. For example, avoid the following:
      // res.srcDirs = ['other/res1', 'other/res1/layouts', 'other/res1/strings']
      // You should specify either only the root 'other/res1' directory, or only the
      // nested 'other/res1/layouts' and 'other/res1/strings' directories.

      // For each source set, you can specify only one Android manifest.
      // By default, Android Studio creates a manifest for your main source
      // set in the src/main/ directory.
      manifest.srcFile 'other/AndroidManifest.xml'
      ...
    }

    // Create additional blocks to configure other source sets.
    androidTest {

      // If all the files for a source set are located under a single root
      // directory, you can specify that directory using the setRoot property.
      // When gathering sources for the source set, Gradle looks only in locations
      // relative to the root directory you specify. For example, after applying the
      // configuration below for the androidTest source set, Gradle looks for Java
      // sources only in the src/tests/java/ directory.
      setRoot 'src/tests'
      ...
    }
  }
}
...

ソースセットでビルドする

ソースセットディレクトリには、特定の設定でのみパッケージ化するコードやリソースを入れておくことができます。たとえば、"demo" プロダクトフレーバーと "debug" ビルドタイプを組み合わせた "demoDebug" ビルドバリアントをビルドしている場合、Gradle はこれらのディレクトリを参照し、次の優先順位を付与します。

src/demoDebug/（ビルドバリアントのソースセット）
src/debug/（ビルドタイプのソースセット）
src/demo/（プロダクトフレーバーのソースセット）
src/main/（メインソースセット）

注: 複数のプロダクトフレーバーを組み合わせる場合、プロダクトフレーバーの優先順位は各プロダクトフレーバーが属するフレーバーディメンションによって決まります。android.flavorDimensions プロパティでフレーバーディメンションを一覧表示すると、最初に表示されるフレーバーディメンジョンに属するプロダクトフレーバーが、2 番目のフレーバーディメンションに属するプロダクトフレーバーより優先順が高く、以降同様に続きます。また、プロダクトフレーバーの組み合わせに対して作成されたソースセットは、個別の各プロダクトフレーバーに属するソースセットよりも優先されます。

上記の順番により、Gradle がコードとリソースを組み合わせるときに、より優先度の高いソースセットが判別されます。demoDebug/ ソースセットディレクトリにはそのビルドバリアント固有のファイルが含まれる可能性が高いため、demoDebug/ に debug/ でも定義されているファイルが含まれている場合、Gradle では demoDebug/ ソースセットのファイルを使用します。Gradle では同様に、ビルドタイプとプロダクトフレーバーのソースセットのファイルに対して、main/ にある同等のファイルよりも高い優先度を付与します。Gradle では、以下のビルドルールを適用するときに、この優先順位が考慮されます。

単一の出力を生成するために、java/ ディレクトリのすべてのソースコードがコンパイルされます。
注: 特定のビルドバリアントについては、同じ Java クラスを定義している 2 つ以上のソースセットディレクトリがある場合、Gradle はビルドエラーをスローします。たとえば、デバッグ APK をビルドするときに、src/debug/Utility.java と src/main/Utility.java の両方を定義することはできません。Gradle はビルドプロセスの際にこれらの両方のディレクトリを参照し、"duplicate class" エラーをスローするためです。ビルドタイプ応じて異なるバージョンの Utility.java が必要な場合は、各ビルドタイプで独自のバージョンのファイルを定義し、そのファイルを main/ ソースセットに含めないようにします。
複数のマニフェストは単一のマニフェストに統合され、上記のリストと同じ優先順位が付与されます。つまり、ビルドタイプのマニフェスト設定により、プロダクトフレーバーなどのマニフェスト設定がオーバーライドされます。詳細については、マニフェストのマージをご覧ください。
同様に、values/ ディレクトリ内のファイルが統合されます。strings.xml ファイルが 2 つある場合など、、2 つのファイルが同じ名前を共有している場合は、上記のリストと同じ優先順位が付与されます。つまり、ビルドタイプのソースセットのファイルで定義されている値により、プロダクトフレーバーなどの同じファイルで定義されている値がオーバーライドされます。
res/ ディレクトリと asset/ ディレクトリ内のリソースは一緒にパッケージ化されます。2 つ以上のソースセットで同じ名前が定義されている複数のリソースがある場合、上記のリストと同じ優先順が付与されます。
最後に、Gradle は APK をビルドするときに、ライブラリモジュールの依存関係に含まれているリソースとマニフェストに最も低い優先順位を付与します。

依存関係の宣言

次の例では、app/ モジュールの build.gradle ファイルで、3 つの異なるタイプの直接的な依存関係を宣言しています。

android {...}
...
dependencies {
    // The 'compile' configuration tells Gradle to add the dependency to the
    // compilation classpath and include it in the final package.

    // Dependency on the "mylibrary" module from this project
    compile project(":mylibrary")

    // Remote binary dependency
    compile 'com.android.support:appcompat-v7:27.1.1'

    // Local binary dependency
    compile fileTree(dir: 'libs', include: ['*.jar'])
}

これらの直接的な依存関係の説明は次のとおりです。

モジュールの依存関係: compile project(':mylibrary') の行で、"mylibrary" という名前の Android ローカルライブラリモジュールを依存関係として宣言し、アプリをビルドするときにそのローカルモジュールをコンパイルして含めるようビルドシステムに要求しています。
リモートバイナリの依存関係: compile 'com.android.support:appcompat-v7:27.1.1' の行では、JCenter 座標を指定して、バージョン 27.1.1 の Android Support Library の依存関係を宣言しています。デフォルトでは、Android Studio は、トップレベルのビルドファイルで JCenter Repository を使用するようにプロジェクトを設定します。プロジェクトとビルド設定ファイルを同期すると、Gradle は JCenter から依存関係を自動的に取り込みます。または、SDK Manager を使用して、特定の依存関係をダウンロードしてインストールすることができます。
ローカルバイナリの依存関係: compile fileTree(dir: 'libs', include: ['*.jar']) の行では、コンパイルクラスパスおよびアプリの最終パッケージの app/libs/ ディレクトリ内に JAR ファイルを含めるようにビルドシステムに指定しています。ローカルバイナリの依存関係が必要なモジュールがある場合、これらの依存関係の JAR ファイルをプロジェクトの <moduleName>/libs にコピーします。

モジュールの直接的な依存関係の中には、モジュールの「推移的な依存関係」と呼ばれる独自の依存関係を持つものがあります。推移的な各依存関係を手動で宣言しなくても、Gradle では、これらの依存関係が自動的に収集および追加されます。Android Plugin for Gradle では、各ビルドバリアントとテストソースセットの依存関係ツリーを生成できる便利な Gradle タスクが提供されているため、モジュールの直接的および推移的な依存関係の両方を簡単に視覚化することができます。このレポートを生成するには、次の手順を実行します。

IDE ウィンドウの右側にある [Gradle] をクリックします。
[MyApplication] > [Tasks] > [android] に移動し、[androidDependencies] をダブルクリックします。
レポートを表示するには、IDE ウィンドウの下部にある [Gradle Console] をクリックします。

次のサンプルレポートはデバッグビルドバリアントの依存関係ツリーを示しており、このツリーには、前の例のローカルモジュールの依存関係とリモートの依存関係が含まれています。

Executing tasks: [androidDependencies]
:app:androidDependencies
debug
/**
 * Both the library module dependency and remote binary dependency are listed
 * with their transitive dependencies.
 */
+--- MyApp:mylibrary:unspecified
|    \--- com.android.support:appcompat-v7:27.1.1
|         +--- com.android.support:animated-vector-drawable:27.1.1
|         |    \--- com.android.support:support-vector-drawable:27.1.1
|         |         \--- com.android.support:support-v4:27.1.1
|         |              \--- LOCAL: internal_impl-27.1.1.jar
|         +--- com.android.support:support-v4:27.1.1
|         |    \--- LOCAL: internal_impl-27.1.1.jar
|         \--- com.android.support:support-vector-drawable:27.1.1
|              \--- com.android.support:support-v4:27.1.1
|                   \--- LOCAL: internal_impl-27.1.1.jar
\--- com.android.support:appcompat-v7:27.1.1
     +--- com.android.support:animated-vector-drawable:27.1.1
     |    \--- com.android.support:support-vector-drawable:27.1.1
     |         \--- com.android.support:support-v4:27.1.1
     |              \--- LOCAL: internal_impl-27.1.1.jar
     +--- com.android.support:support-v4:27.1.1
     |    \--- LOCAL: internal_impl-27.1.1.jar
     \--- com.android.support:support-vector-drawable:27.1.1
          \--- com.android.support:support-v4:27.1.1
               \--- LOCAL: internal_impl-27.1.1.jar
...

Gradle での依存関係の管理に関する詳細については、Gradle のユーザーガイドの依存関係管理の基本をご覧ください。

依存関係の設定

前の例にある compile キーワードなどの特定の設定キーワードを使用して、依存関係を使用する方法とタイミングを Gradle に対して指定することができます。以下に、依存関係の設定に使用できるキーワードをいくつか紹介します。

compile: コンパイル時の依存関係を指定します。Gradle は、この設定を使用して依存関係をクラスパスとアプリの APK に追加します。これはデフォルトの設定です。
apk: Gradle でアプリの APK をパッケージ化するために必要な実行時のみの依存関係を指定します。この設定は JAR バイナリの依存関係と併用できますが、他のライブラリモジュールの依存関係や AAR バイナリの依存関係とは併用できません。
provided: Gradle でアプリの APK と一緒にパッケージ化されないコンパイル時の依存関係を指定します。これは、実行時に依存関係が要求されない場合に、APK のサイズを削減するのに役立ちます。この設定は JAR バイナリの依存関係と併用できますが、他のライブラリモジュールの依存関係や AAR バイナリの依存関係とは併用できません。

また、次のサンプルで示しているように、ビルドバリアントまたはテストソースセットの名前を設定キーワードに適用することにより、特定のビルドバリアントまたはテストソースセットの依存関係を設定することができます。

dependencies {
    ...
    // Adds specific library module dependencies as compile time dependencies
    // to the fullRelease and fullDebug build variants.
    fullReleaseCompile project(path: ':library', configuration: 'release')
    fullDebugCompile project(path: ':library', configuration: 'debug')

    // Adds a compile time dependency for local tests.
    testCompile 'junit:junit:4.12'

    // Adds a compile time dependency for the test APK.
    androidTestCompile 'com.android.support.test.espresso:espresso-core:3.0.2'
}

署名設定の設定

Gradle では、このビルドの署名設定を明示的に定義しない限り、リリースビルドの APK に署名されません。リリースキーの作成と、Android Studio での release ビルドタイプの署名は簡単に行うことができます。

Gradle ビルド設定を使用して、release ビルドタイプの署名設定を手動で設定するには、次の手順を実行します。

キーストアを作成します。キーストアは一連のプライベートキーを含んだバイナリファイルです。キーストアは安全な場所に保管する必要があります。
プライベートキーを作成します。プライベートキーは、人や会社など、アプリで識別されるエンティティを表します。

署名設定をモジュールレベルの build.gradle ファイルに追加します。

...
android {
    ...
    defaultConfig {...}
    signingConfigs {
        release {
            storeFile file("myreleasekey.keystore")
            storePassword "password"
            keyAlias "MyReleaseKey"
            keyPassword "password"
        }
    }
    buildTypes {
        release {
            ...
            signingConfig signingConfigs.release
        }
    }
}

署名済みの APK を生成するには、メニューバーから [Build] > [Generate Signed APK] を選択します。これで、app/build/apk/app-release.apk 内のパッケージがリリースキーによって署名されました。

注: リリースキーとキーストアのパスワードをビルドファイルに含めることは、セキュリティ上の理由からお勧めできません。代わりに、これらのパスワードを環境変数から取得するか、ビルドプロセスによってこれらのパスワードが要求されるようにビルドファイルを設定できます。

これらのパスワードを環境変数から取得する方法:

storePassword System.getenv("KSTOREPWD")
keyPassword System.getenv("KEYPWD")

コマンドラインからビルドを開始する場合に、ビルドプロセスによってこれらのパスワードが要求されるようにする方法:

storePassword System.console().readLine("\nKeystore password: ")
keyPassword System.console().readLine("\nKey password: ")

このプロセスが完了したら、アプリを配布したり、Google Play で公開したりできます。

警告: キーストアとプライベートキーは安全な場所に保管し、セキュアバックアップを取るようにしてください。アプリのすべてのバージョンは常に同じキーで署名する必要があるため、アプリを Google Play に公開した後でアプリの署名に使用したキーをなくした場合、アプリに対してアップデートを公開できなくなります。

Android Wear アプリに署名する

Android Wear アプリを公開する場合、ユーザーはウェアラブル端末上で直接アプリを閲覧してインストールできないため、ウェアラブルアプリをハンドヘルドアプリ内にパッケージ化します。署名は両方のアプリに付ける必要があります。Android Wear アプリのパッケージ化と署名の詳細については、ウェアラブルアプリのパッケージ化をご覧ください。

ビルド バリアントの設定