サイトのトップへ戻る

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

サイト内検索

ビルドバリアントを設定する

このページでは ビルド構成設定の概要 に基づき、 ビルドバリアントを設定して一つのプロジェクトから異なるバージョンのアプリを作成する方法と、 依存関係の管理と設定の署名を適切に行う方法について説明します。

ビルドバリアント はアプリでビルド可能な別バージョンを表します。 例えば、あなたは機能を制限した無料バージョンのアプリと機能を追加した有料バージョンのアプリをビルドしたいかもしれません。 またAPIレベルやその他端末要件に基づき、別個の端末を対象とした異なるバージョンのアプリをビルドすることもできます。 ですが、デバイスAPIや画面密度に基づいて異なるバージョンをビルドしたい場合は、代わりに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
        }
    }
}

Note: ビルド設定ファイルを変更した時、Android Studio ではプロジェクトと新しい設定を同期させる必要があります。 プロジェクトを同期するには、変更を行った際に通知バーに表示される Sync Nowか、ツールバーのSync Project をクリックします。 Android Studio が設定のエラーを通知する場合、Messages ウィンドウが表示されてその問題を説明します。

ビルドタイプで設定できる全てのプロパティについてさらに学ぶには、BuildType DSL リファレンスを参照してください。



プロダクトフレーバーを設定する

プロダクトフレーバーの作成はビルドタイプの作成と同じです。: productFlavors {} ブロックにプロダクトフレーバーを追加し、必要な設定を行います。 プロダクトフレーバーはdefaultConfigと同じプロパティをサポートしています。—これは、 defaultConfig が実際はProductFlavor クラスの属しているためです。 つまり、 defaultConfig {}内で全てのフレーバー用の基本設定を行い、 各フレーバーではそれらの既定値(applicationIdなど)を上書きすることができます

メモ: ここでも、 main/ マニフェストファイル内の package属性を使ってパッケージ名を指定する必要があります。 また、ソースコード上ではこのパッケージ名を使ってRクラスを参照するか、相対アクティビティやservice registrationの名前解決を行う必要があります。 これにより、ソースコードを変更せずに、applicationIdを使って、各プロダクトフレーバーにパッケージ用もしくは配布用の重複のないIDを付与することができます。

以下のコード例では、独自のapplicationIdversionNameを持ったプロダクトフレーバー、"demo" と"full"を作成しています。

android {
    ...
    defaultConfig {...}
    buildTypes {...}
    productFlavors {
        demo {
            applicationId "com.example.myapp.demo"
            versionName "1.0-demo"
        }
        full {
            applicationId "com.example.myapp.full"
            versionName "1.0-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と進んでドロップダウンメニューから一つ選ぶだけです。 ですが、各ビルドバリアントを独自の機能やリソースを持ったものにカスタマイズするには、ソースセットの作成・管理方法を知っておく必要があります。



ビルドバリアント用のソースセットを作成する

既定ではAndroid Studioは、main/ ソースセット とディレクトリを作成します。 このディレクトリには全ビルドバリアントで共有するものが置かれます。 しかし、特定のビルドタイプやプロダクトフレーバーやビルドバリアントについて新たにソースセットを作成し、Gradleがコンパイル・パッケージ化するファイルを正確に制御することができます。 例えば、main/ ソースセットに基本機能を定義し、プロダクトフレーバーのソースセットを使って異なるクライアントごとにアプリのブランディングを変更したり、 デバッグ用ビルドタイプを使用するビルドバリアントの場合のみに特別な権限やログ機能を実装したりできます。

Gradle では、ソースセットとディレクトリをmain/ ソースセットと同様のやり方で配置することが求められます。 例えばGradleは、 "debug" ビルドタイプ固有のJava クラスファイルは src/debug/java/ ディレクトリに置かれることを想定しています。

Gradle 用の Android プラグインでは、各ビルドタイプとプロダクトフレーバーとビルドバリアントのファイルをどのように配置するかを示す便利な機能が付いています。 例えば以下のレポートでは、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/testing source setsのような、アプリのテストを実行するために使うファイル用のソースセットをどのように配置するかについても表示します。

ビルドバリアントを新規に作成した時、Android Studio があなたに代わってソースセットのディレクトリを作成することはありませんが、 ディレクトリの作成に役立ついくつかのオプションが用意されています。 例えば、"debug"ビルドタイプ用のe java/ディレクトリを作成するには、以下のようにします:

  1. Project パネルを開き、パネルの上部にあるドロップダウンメニューから Project ビューを選びます。
  2. MyProject/app/src/を開きます。
  3. src ディレクトリを右クリックし、New > Folder > Java Folderの順で選びます。
  4. Target Source Setの隣にあるドロップダウンメニューから、debugを選びます。
  5. Finishをクリックします。

Android Studio はあなたのデバッグビルドタイプ用のソースセットディレクトリを作成し、その中に java/ ディレクトリを作成します。 Alternatively, you can also make Android Studio create the directories for you when create a new file for a specific build variant. 例えば、 "debug"ビルドタイプ用のValues XML ファイルを作成するには:

  1. 同じ Project パネル上で、srcディレクトリを右クリックし、 New > XML > Values XML Fileの順で選びます。
  2. XML ファイルの名前を入力するか、既定の名前のままにします。
  3. Target Source Setの隣のドロップダウンメニューから、debugを選びます。
  4. Finishをクリックします。

"debug" ビルドタイプが target source setとして選択されたので、 Android Studio はXMLファイルを作成する時に必要なディレクトリを自動的に作成します。 その結果、ディレクトリ構造は図 2のようになります。

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

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



ソースセットを使用したビルド

ソースセットディレクトリを使用して、特定の構成でのみパッケージしたいコードとリソースを含めることができます。 例えば"demoDebug"ビルドバリアント( "demo" プロダクトフレーバーと "debug" ビルドタイプの複合物)をビルドしている場合、 Gradle はこれらのディレクトリを見て以下のような優先順位を付けます。:

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

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

  • java/ ディレクトリ内の全てのソースコードは一緒にコンパイルされ、一つに出力されます。

    メモ: 設定されたビルドバリアントについて、二つ以上のソースセットで同じ名前のJavaクラスが定義されていた場合、Gradle はビルドエラーを投げます。 例えば、デバッグ用APKをビルドしている時、src/debug/Utility.javasrc/main/Utility.javaの両方を定義することはできません。 これは、ビルド処理中にGradle がこれら両方のディレクトリを参照して'重複クラス'エラーを投げるからです。 If you want different versions of Utility.java for different build types, you can have each build type define its own version of the file and not include it in the main/ source set.

  • 全てのマニフェストは一つに結合されます。前述の一覧の時と同じように優先順序が付けられます。 つまり、ビルドタイプのマニフェスト設定はプロダクトフレーバーのマニフェスト設定より優先される、などです。 詳細についてはマニフェストを結合するを参照してください。
  • 同様に、values/ ディレクトリ内の各ファイルも一つに結合されます。 strings.xml ファイルが二つある、といったように二つのファイルで同じ名前のものがある場合、前述の一覧の時と同じように優先順序が付けられます。 つまり、ビルドタイプのソースセットで定義された値はプロダクトフレーバーの同じ名前のファイルで定義された値より優先される、などです。
  • res/ ディレクトリとasset/ ディレクトリ内の各リソースは一つにパッケージされます。 二つ以上のソースセットで同じ名前のリソースが定義されている場合、前述の一覧の時と同じように優先順序が付けられます。
  • Finally, Gradle gives resources and manifests included with library module dependencies the lowest priority when building the APK.


依存関係を宣言する

以下の例では、app/モジュールのbuild.gradle ファイル内で、三種類の直接依存関係を宣言しています。:

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.0.1'

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

これらの直接依存関係については、以下で説明します。

Module dependencies
compile project(':mylibrary') の行では "mylibrary" という名前の ローカルAndroid ライブラリモジュールを依存ファイルとして宣言しており、アプリをビルドする際にはビルドシステムがこのローカルモジュールをコンパイルしてインクルードする必要があります。
Remote binary dependencies
compile 'com.android.support:appcompat-v7:25.0.1' の行では、JCenter 座標を指定することでAndroid サポートライブラリ のバージョン 25.0.1を依存ファイルとして宣言しています。 既定では、Android Studioはプロジェクトを設定してトップレベルビルドファイルのJCenter リポジトリを使うようにします。 プロジェクトとビルド設定ファイルの同期を行うと、Gradleは自動的にJCenter から依存ファイルを取ってきます。 それ以外にも、 SDK Managerを使うことで特定の依存ファイルのダウンロードとインストールをすることができます。
Local binary dependencies
compile fileTree(dir: 'libs', include: ['*.jar']) の行では、app/libs/ディレクトリ内のJARファイルをコンパイルクラスパスとアプリの最終パッケージに インクルードするようビルドシステムに指示をしています。 ローカルバイナリ依存ファイルが必要なモジュールがある場合は、そのJARファイルをプロジェクトの <moduleName>/libs内にコピーしてください。

モジュールで使用されているのいくつかの直接依存ファイルは、それ独自の依存関係を持っています。これはモジュールの推移的依存と呼ばれます。 推移的依存は手動で宣言する必要は無く、あなたに代わってGradle が自動的に検知して追加します。 Gradle 用 Android プラグインには各ビルドバリアントと テストするソースセットごとの依存関係ツリーを生成することができる便利な機能があるため。モジュールの直接依存・推移依存の両方を簡単に可視化することができます。 このレポートを生成するには、以下の手順を行ってください:

  1. IDE画面の右側にあるGradle をクリックします。
  2. MyApplication > Tasks > android と進んで androidDependenciesをダブルクリックします。
  3. レポートを見るには、IDE画面の下部にある Gradle Console をクリックします。

以下のレポート例では、デバッグ用ビルドバリアントの依存関係ツリーを表示しています。 前回の例にあったlocal module dependencyとremote dependencyが依存関係に含まれています。

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.0.1
|         +--- com.android.support:animated-vector-drawable:25.0.1
|         |    \--- com.android.support:support-vector-drawable:25.0.1
|         |         \--- com.android.support:support-v4:25.0.1
|         |              \--- LOCAL: internal_impl-25.0.1.jar
|         +--- com.android.support:support-v4:25.0.1
|         |    \--- LOCAL: internal_impl-25.0.1.jar
|         \--- com.android.support:support-vector-drawable:25.0.1
|              \--- com.android.support:support-v4:25.0.1
|                   \--- LOCAL: internal_impl-25.0.1.jar
\--- com.android.support:appcompat-v7:25.0.1
     +--- com.android.support:animated-vector-drawable:25.0.1
     |    \--- com.android.support:support-vector-drawable:25.0.1
     |         \--- com.android.support:support-v4:25.0.1
     |              \--- LOCAL: internal_impl-25.0.1.jar
     +--- com.android.support:support-v4:25.0.1
     |    \--- LOCAL: internal_impl-25.0.1.jar
     \--- com.android.support:support-vector-drawable:25.0.1
          \--- com.android.support:support-v4:25.0.1
               \--- LOCAL: internal_impl-25.0.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を使うと簡単にリリース用キーを作成して リリース用ビルドタイプを署名することができます。

Gradle のビルド設定を使って手動でリリースビルドタイプ用の署名設定を設定するには、以下のようにします。:

  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 に出力されるパッケージにはリリースキーが署名されます。

Note: リリースキー用パスワードとキーストアをビルドファイルに含めるのは、セキュリティー上よろしくありません。 代わりに、環境変数からこれらパスワードを取得したり、ビルド処理時にパスワードを入力させるようにしたりするよう、ビルドファイルを設定することができます。

環境変数からこれらパスワードを取得するには、以下のようにします:

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

コマンドラインからビルドを実行した際にパスワードの入力を求めるようにするには、以下のようにします:

storePassword System.console().readLine("
Keystore password: ")
keyPassword System.console().readLine("
Key password: ")

この処理が完了したら、アプリを配布して Google Play上で公開できます。

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



Android Wear アプリを署名する

Android Wear アプリを配信する際には、携帯アプリ内にウェアラブルアプリをパッケージします。 ユーザーはウェアラブル端末上でアプリの閲覧やインストールができないためです。 Android Wear アプリのパッケージや署名に関する詳細については、Packaging Wearable Appsを参照してください。




エンジェル戦記