Register now for Android Dev Summit 2019!

ビルド バリアントの設定

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

ビルド バリアントは、ビルド可能なさまざまなバージョンのアプリを表しています。たとえば、コンテンツが制限された無料版のアプリと多くのコンテンツが含まれた有料版のアプリを作成することができます。また、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" というプロダクト フレーバーを追加しています。これらのフレーバーでは、applicationIdSuffixversionNameSuffix という独自のフレーバーを提供しています。

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]

この出力を表示するには、次の手順を実行します。

  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 ではデバッグ ビルドタイプ用のソースセット ディレクトリを作成してから、そのディレクトリ内に 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 では、以下のビルドルールを適用するときに、この優先順位が考慮されます。

  • 単一の出力を生成するために、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 アプリのパッケージ化と署名の詳細については、ウェアラブル アプリのパッケージ化をご覧ください。