Skip to content

Most visited

Recently visited

navigation

ビルド バリアントの設定

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

各ビルド バリアントは、ビルド可能なさまざまなバージョンのアプリを表しています。たとえば、コンテンツが制限された無料版のアプリと多くのコンテンツが含まれた有料版のアプリを作成することができます。また、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 は次のビルド バリアントを作成します。

ビルドして実行するビルド バリアントを、この中のいずれかに変更することができます。変更するには、[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]

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

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

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

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

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

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

  1. 同じ [Project] ペインで、src ディレクトリを右クリックし、[New] > [XML] > [Values XML File] を選択します。
  2. XML ファイルの名前を入力するか、デフォルトの名前のままにします。
  3. [Target Source Set] の横にあるプルダウン メニューから [debug] を選択します。
  4. [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 はこれらのディレクトリを参照し、次の優先順位を付与します。

  1. src/demoDebug/(ビルド バリアントのソースセット)
  2. src/debug/(ビルドタイプのソースセット)
  3. src/demo/(プロダクト フレーバーのソースセット)
  4. src/main/(メイン ソースセット)

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

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

依存関係の宣言

次の例では、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:25.3.1'

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

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

モジュールの依存関係
compile project(':mylibrary') の行で、"mylibrary" という名前の Android ローカル ライブラリ モジュールを依存関係として宣言し、アプリをビルドするときにそのローカル モジュールをコンパイルして含めるようビルドシステムに要求しています。
リモート バイナリの依存関係
compile 'com.android.support:appcompat-v7:25.3.1' の行では、JCenter 座標を指定して、バージョン 25.3.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 タスクが提供されているため、モジュールの直接的および推移的な依存関係の両方を簡単に視覚化することができます。このレポートを生成するには、次の手順を実行します。

  1. IDE ウィンドウの右側にある [Gradle] をクリックします。
  2. [MyApplication] > [Tasks] > [android] に移動し、[androidDependencies] をダブルクリックします。
  3. レポートを表示するには、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:25.3.1
|         +--- com.android.support:animated-vector-drawable:25.3.1
|         |    \--- com.android.support:support-vector-drawable:25.3.1
|         |         \--- com.android.support:support-v4:25.3.1
|         |              \--- LOCAL: internal_impl-25.3.1.jar
|         +--- com.android.support:support-v4:25.3.1
|         |    \--- LOCAL: internal_impl-25.3.1.jar
|         \--- com.android.support:support-vector-drawable:25.3.1
|              \--- com.android.support:support-v4:25.3.1
|                   \--- LOCAL: internal_impl-25.3.1.jar
\--- com.android.support:appcompat-v7:25.3.1
     +--- com.android.support:animated-vector-drawable:25.3.1
     |    \--- com.android.support:support-vector-drawable:25.3.1
     |         \--- com.android.support:support-v4:25.3.1
     |              \--- LOCAL: internal_impl-25.3.1.jar
     +--- com.android.support:support-v4:25.3.1
     |    \--- LOCAL: internal_impl-25.3.1.jar
     \--- com.android.support:support-vector-drawable:25.3.1
          \--- com.android.support:support-v4:25.3.1
               \--- LOCAL: internal_impl-25.3.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:2.2.2'
}

署名設定の設定

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

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

  1. キーストアを作成します。キーストアは一連のプライベート キーを含んだバイナリ ファイルです。キーストアは安全な場所に保管する必要があります。
  2. プライベート キーを作成します。プライベート キーは、人や会社など、アプリで識別されるエンティティを表します。
  3. 署名設定をモジュール レベルの 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 アプリのパッケージ化と署名の詳細については、ウェアラブル アプリのパッケージ化をご覧ください。

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

Get the latest Android developer news and tips that will help you find success on Google Play.

* Required Fields

Hooray!

Browse this site in ?

You requested a page in , but your language preference for this site is .

Would you like to change your language preference and browse this site in ? If you want to change your language preference later, use the language menu at the bottom of each page.

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.