ビルド バリアントの設定

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

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

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

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

ビルドタイプの設定

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

特定の設定を追加または変更する場合、debug ビルドタイプを設定に追加することができます。次のサンプルでは、debug ビルドタイプ向けに applicationIdSuffix を指定し、debug ビルドタイプの設定を使用して初期化される「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 つのフレーバー ディメンションのみが指定されている場合、Android Gradle プラグインはモジュールのすべてのフレーバーをそのディメンションに自動的に割り当てます。

  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」というプロダクト フレーバーを追加しています。これらのフレーバーでは、applicationIdSuffixversionNameSuffix という独自のフレーバーを提供しています。

android {
    ...
    defaultConfig {...}
    buildTypes {
        debug{...}
        release{...}
    }
    // Specifies one flavor dimension.
    flavorDimensions "version"
    productFlavors {
        demo {
            // Assigns this product flavor to the "version" flavor dimension.
            // If you are using only one dimension, this property is optional,
            // and the plugin automatically assigns all the module's flavors to
            // that 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/ ソースセットで基本的な機能を定義してプロダクト フレーバーのソースセットでクライアントごとにアプリのブランディングを変えたり、debug ビルドタイプを使用するビルド バリアント専用の特別なパーミッションやログ機能を含めたりすることが可能です。

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] をダブルクリックします。Gradle がタスクを実行すると、[Run] ウィンドウが開いて出力が表示されます。
  3. 上記のようにテキストモードで表示されない場合は、[Run] ウィンドウの左側にある [Toggle view] をクリックします。

注: タスク出力には、アプリのテストを実行するために必要な 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 は debug ビルドタイプのソースセット ディレクトリを作成し、そのディレクトリ内に 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/ ソースセット ディレクトリにはそのビルド バリアント固有のファイルが含まれる可能性が高いため、debug/ で定義されているファイルが demoDebug/ に含まれている場合、Gradle は demoDebug/ ソースセットのファイルを使用します。Gradle では同様に、ビルドタイプとプロダクト フレーバーのソースセットのファイルに対して main/ にある同じファイルよりも高い優先度を付与します。Gradle では、以下のビルドルールを適用するときに、この優先順位が考慮されます。

  • java/ ディレクトリのすべてのソースコードはコンパイルされて、単一の出力が生成されます。

    注: 特定のビルド バリアントについては、同じ Java クラスを定義している 2 つ以上のソースセット ディレクトリがある場合、Gradle はビルドエラーをスローします。たとえば、デバッグ APK をビルドする際に src/debug/Utility.javasrc/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 ビルドタイプの署名設定を手動で設定するには、次の手順を行います。

  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 に公開した後でアプリの署名に使用したキーを紛失した場合、アプリのアップデートを公開できなくなります。

Wear OS アプリの署名

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