ビルドバリアントの設定

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

各ビルドバリアントは、ビルド可能なさまざまなバージョンのアプリを表しています。たとえば、コンテンツが制限された無料版のアプリと多くのコンテンツが含まれた有料版のアプリを作成することができます。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 が実際には ProductFlavor クラスに属しているため、プロダクトフレーバーでは defaultConfig と同じプロパティがサポートされます。つまり、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」のプロダクトフレーバーで異なる設定を作成する必要がある場合などです。これを行うには、Android Plugin for Gradle を使用して、複数のプロダクトフレーバーをフレーバーディメンションとしてグループ化します。アプリをビルドする際、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. デバッグビルドタイプの新しいソースセットディレクトリ。

同じ手順で、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/ ソースセットディレクトリにはそのビルドバリアント固有のファイルが含まれる可能性が高いため、debug/ で定義されているファイルが demoDebug/ に含まれている場合、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 でのリリースビルドタイプの署名は簡単に行うことができます。

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

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

署名設定をモジュールレベルの 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 アプリのパッケージ化と署名について詳しくは、ウェアラブルアプリのパッケージ化をご覧ください。

ビルド バリアントの設定