ビルドバリアントの設定

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

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

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

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

ビルドタイプの設定

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

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

android {
    defaultConfig {
        manifestPlaceholders = [hostName:"www.example.com"]
        ...
    }
    buildTypes {
        release {
            minifyEnabled true
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        }

        debug {
            applicationIdSuffix ".debug"
            debuggable true
        }

        /**
         * The `initWith` property allows you to copy configurations from other build types,
         * then configure only the settings you want to change. This one copies the debug build
         * type, and then changes the manifest placeholder and application ID.
         */
        staging {
            initWith debug
            manifestPlaceholders = [hostName:"internal.example.com"]
            applicationIdSuffix ".debugStaging"
        }
    }
}

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

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

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

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

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

すべてのフレーバーは、名前の付いたフレーバーディメンションに属していなければなりません。フレーバーディメンションとは、プロダクトフレーバーのグループです。1 つのディメンションしか使用しない場合でも、フレーバーディメンションにはフレーバーを割り当てる必要があります。割り当てない場合、次のビルドエラーが発生します。

  Error:All flavors must now belong to a named flavor dimension.
  The flavor 'flavor_name' is not assigned to a flavor dimension.

次のコードサンプルでは、"version" という名前のフレーバーディメンションを作成し、"demo" と "full" というプロダクトフレーバーを追加しています。これらのフレーバーでは、applicationIdSuffix と versionNameSuffix という独自のフレーバーを提供しています。

android {
    ...
    defaultConfig {...}
    buildTypes {
        debug{...}
        release{...}
    }
    // Specifies one flavor dimension.
    flavorDimensions "version"
    productFlavors {
        demo {
            // Assigns this product flavor to the "version" flavor dimension.
            // This property is optional if you are using only one dimension.
            dimension "version"
            applicationIdSuffix ".demo"
            versionNameSuffix "-demo"
        }
        full {
            dimension "version"
            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] をダブルクリックします。Gradle がタスクを実行すると、[Run] ウィンドウが開いて出力が表示されます。
上記のようにテキストモードで表示されない場合は、[Run] ウィンドウの左側にある [Toggle view] をクリックします。

注:タスク出力には、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 をビルドするときに、ライブラリモジュールの依存関係に含まれているリソースとマニフェストに最も低い優先順位を付与します。

依存関係の宣言

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

dependencies {
    // Adds the local "mylibrary" module as a dependency to the "free" flavor.
    freeImplementation project(":mylibrary")

    // Adds a remote binary dependency only for local tests.
    testImplementation 'junit:junit:4.12'

    // Adds a remote binary dependency only for the instrumented test APK.
    androidTestImplementation '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 に公開した後でアプリの署名に使用したキーをなくした場合、アプリに対してアップデートを公開できなくなります。

Wear OS アプリの署名

Wear OS アプリを公開する際は、時計の APK と、オプションのスマートフォンの APK の両方を署名する必要があります。Wear OS アプリのパッケージ化と署名の詳細については、ウェアラブルアプリのパッケージ化をご覧ください。

ビルド バリアントの設定