次の方法で共有

リリースのためのアプリケーションの準備

アプリケーションのコーディングとテストが完了したら、配布用のパッケージを準備する必要があります。 このパッケージを準備する最初のタスクは、リリース用のアプリケーションをビルドすることです。これには、主にいくつかのアプリケーション属性の設定が必要です。

リリース用のアプリをビルドするには、次の手順に従います。

  • アプリケーション アイコンを指定する – 各 Xamarin.Android アプリケーションには、アプリケーション アイコンが指定されている必要があります。 技術的には必要ではありませんが、Google Play などの一部の市場では必要です。

  • アプリケーションのバージョン 管理 – この手順では、バージョン情報を初期化または更新します。 これは、今後のアプリケーション更新プログラムと、ユーザーがインストールしたアプリケーションのバージョンを確実に認識するために重要です。

  • APK を縮小する – マネージド コードで Xamarin.Android リンカーを使用し、Java バイトコードで ProGuard を使用することで、最終的な APK のサイズを大幅に縮小できます。

  • アプリケーションの保護 – デバッグを無効にし、マネージド コードを難読化し、デバッグと改ざん防止を追加し、ネイティブ コンパイルを使用して、ユーザーまたは攻撃者がアプリケーションのデバッグ、改ざん、リバース エンジニアリングを行わないようにします。

  • パッケージ化プロパティの設定 – パッケージ化プロパティは、Android アプリケーション パッケージ (APK) の作成を制御します。 この手順では、APK を最適化し、その資産を保護し、必要に応じてパッケージをモジュール化します。 さらに、デバイス用に最適化された Android アプリ バンドルをユーザーに提供することもできます。

  • コンパイル – この手順では、コードとアセットをコンパイルして、リリース モードでビルドされることを確認します。

  • 発行用のアーカイブ – この手順では、アプリをビルドし、署名と発行用のアーカイブに配置します。

これらの各手順について、以下で詳しく説明します。

アプリケーション アイコンを指定する

各 Xamarin.Android アプリケーションでアプリケーション アイコンを指定することを強くお勧めします。 一部のアプリケーションマーケットプレースでは、それがないとAndroidアプリケーションを公開できません。 Application属性の Icon プロパティは、Xamarin.Android プロジェクトのアプリケーション アイコンを指定するために使用されます。

Visual Studio 2017 以降では、次のスクリーンショットに示すように、プロジェクトの [プロパティ] の [Android マニフェスト] セクションでアプリケーション アイコンを指定します。

アプリケーション アイコンを設定する

これらの例では、 @drawable/icon は Resources/drawable/icon.png にあるアイコン ファイルを参照します ( .png 拡張子はリソース名に含まれていないことに注意してください)。 この属性は、次のサンプル スニペットに示すように、 Properties\AssemblyInfo.cs ファイルで宣言することもできます。

[assembly: Application(Icon = "@drawable/icon")]

通常、 using Android.App は AssemblyInfo.cs の先頭で宣言されます ( Application 属性の名前空間は Android.App)。ただし、この using ステートメントがまだ存在しない場合は、追加する必要があります。

アプリケーションのバージョン化

バージョン管理は、Android アプリケーションのメンテナンスと配布に重要です。 何らかのバージョン管理が行われなければ、アプリケーションを更新する必要があるかどうかや方法を判断するのは困難です。 バージョン管理を支援するために、Android は次の 2 種類の情報を認識します。

  • バージョン番号 – アプリケーションのバージョンを表す整数値 (Android とアプリケーションによって内部的に使用されます)。 ほとんどのアプリケーションは、この値を 1 に設定して開始し、ビルドごとにインクリメントされます。 この値には、バージョン名属性とのリレーションシップまたはアフィニティはありません (以下を参照)。 アプリケーションと発行サービスでは、この値をユーザーに表示しないでください。 この値は、android:versionCodeとしてAndroidManifest.xml ファイルに格納されます。

  • バージョン名 – (特定のデバイスにインストールされている) アプリケーションのバージョンに関する情報をユーザーに伝達するためにのみ使用される文字列。 バージョン名は、ユーザーまたは Google Play に表示されることを目的としています。 この文字列は、Android では内部的には使用されません。 バージョン名には、ユーザーがデバイスにインストールされているビルドを識別するのに役立つ任意の文字列値を指定できます。 この値は、android:versionNameとしてAndroidManifest.xml ファイルに格納されます。

Visual Studio では、次のスクリーンショットに示すように、これらの値はプロジェクトの [プロパティ] の [Android マニフェスト] セクションで設定できます。

バージョン番号を設定する

APK を縮小する

不要なマネージド コードを削除する Xamarin.Android リンカーと、未使用の Java バイトコードを削除する Android SDK から ProGuard ツールを組み合わせることで、Xamarin.Android API を小さくできます。 ビルド プロセスでは、まず Xamarin.Android リンカーを使用してマネージド コード (C#) レベルでアプリを最適化し、後で ProGuard (有効な場合) を使用して Java バイトコード レベルで APK を最適化します。

リンカーを構成する

リリース モードでは、共有ランタイムをオフにし、リンクをオンにして、実行時に必要な Xamarin.Android の一部のみがアプリケーションに付属するようにします。 Xamarin.Android の リンカー は、静的分析を使用して、Xamarin.Android アプリケーションで使用または参照されるアセンブリ、型、および型のメンバーを決定します。 その後、リンカーは、使用されていない (または参照されていない) 未使用のアセンブリ、型、およびメンバーをすべて破棄します。 これにより、パッケージ サイズが大幅に削減される可能性があります。 たとえば、APK の最終的なサイズが 83% 減少する HelloWorld サンプルを考えてみましょう。

  • 構成: なし – Xamarin.Android 4.2.5 サイズ = 17.4 MB。

  • 構成: SDK アセンブリのみ – Xamarin.Android 4.2.5 サイズ = 3.0 MB。

プロジェクトの [プロパティ] の [Android オプション] セクションでリンカー オプションを設定します。

リンカー オプション

[ リンク] プルダウン メニューには、リンカーを制御するための次のオプションがあります。

  • なし – リンカーをオフにします。リンクは実行されません。

  • SDK アセンブリのみ – これにより、Xamarin.Android で必要なアセンブリのみがリンクされます。 他のアセンブリはリンクされません。

  • Sdk アセンブリとユーザー アセンブリ – これにより、Xamarin.Android で必要なアセンブリだけでなく、アプリケーションで必要なすべてのアセンブリがリンクされます。

リンクすると意図しない副作用が発生する可能性があるため、アプリケーションを物理デバイスのリリース モードで再テストすることが重要です。

ProGuard

ProGuard は、Java コードをリンクして難読化する Android SDK ツールです。 ProGuard は通常、APK に含まれる大規模なライブラリ (Google Play Services など) のフットプリントを減らすことで、より小さなアプリケーションを作成するために使用されます。 ProGuard は、未使用の Java バイトコードを削除します。これにより、結果として得られるアプリが小さくなります。 たとえば、小規模な Xamarin.Android アプリで ProGuard を使用すると、通常、サイズが約 24% 削減されます。通常、複数のライブラリ依存関係を持つ大規模なアプリで ProGuard を使用すると、さらに大きなサイズの削減が実現されます。

ProGuard は、Xamarin.Android リンカーに代わるものではありません。 Xamarin.Android リンカーは マネージド コードをリンクし、ProGuard は Java バイトコードをリンクします。 ビルド プロセスでは、最初に Xamarin.Android リンカーを使用してアプリのマネージド (C#) コードを最適化し、後で ProGuard (有効な場合) を使用して Java バイトコード レベルで APK を最適化します。

[ProGuard を有効にする] がオンの場合、Xamarin.Android は結果の APK で ProGuard ツールを実行します。 ProGuard 構成ファイルが生成され、ビルド時に ProGuard によって使用されます。 Xamarin.Android では、カスタム ProguardConfiguration ビルド アクションもサポートされています。 次の例に示すように、カスタム ProGuard 構成ファイルをプロジェクトに追加して右クリックし、ビルド アクションとして選択できます。

ProGuard は既定で無効になっています。 [ProGuard を有効にする] オプションは、プロジェクトがリリース モードに設定されている場合にのみ使用できます。 [ProGuard を有効にする] がオンでない限り 、すべての ProGuard ビルド アクションは無視されます。 Xamarin.Android ProGuard 構成は APK を難読化せず、カスタム構成ファイルを使用しても難読化を有効にすることはできません。 難読化を使用する場合は、 Dotfuscator によるアプリケーション保護を参照してください。

ProGuard ツールの使用方法の詳細については、「 ProGuard」を参照してください。

アプリケーションを保護する

デバッグを無効にする

Android アプリケーションの開発中は、 Java Debug Wire Protocol (JDWP) を使用してデバッグが実行されます。 これは、 adb などのツールがデバッグのために JVM と通信できるようにするテクノロジです。 Xamarin.Android アプリケーションのデバッグ ビルドでは、既定で JDWP が有効になっています。 JDWP は開発中に重要ですが、リリースされたアプリケーションではセキュリティの問題が発生する可能性があります。

Von Bedeutung

(JDWP を介して) Java プロセスへのフル アクセスを取得し、このデバッグ状態が無効でない場合は、アプリケーションのコンテキストで任意のコードを実行できるため、リリースされたアプリケーションのデバッグ状態を常に無効にします。

Android マニフェストには、アプリケーションをデバッグできるかどうかを制御する android:debuggable 属性が含まれています。 android:debuggable属性を false に設定することをお勧めします。 これを行う最も簡単な方法は、 AssemblyInfo.csに条件付きコンパイル ステートメントを追加することです。

#if DEBUG
[assembly: Application(Debuggable=true)]
#else
[assembly: Application(Debuggable=false)]
#endif

デバッグ ビルドでは、デバッグが容易になるように ( インターネット や ReadExternalStorage など) いくつかのアクセス許可が自動的に設定されることに注意してください。 ただし、リリース ビルドでは、明示的に構成したアクセス許可のみを使用します。 リリース ビルドに切り替えると、デバッグ ビルドで使用できるアクセス許可がアプリで失われる場合は、「アクセス許可」の説明に従って、必要なアクセス許可の一覧でこのアクセス許可を明示的に有効にしていることを確認します。

Dotfuscator を使用したアプリケーション保護

デバッグを無効にしても、攻撃者はアプリケーションを再パッケージ化し、構成オプションやアクセス許可を追加または削除することができます。 これにより、アプリケーションのリバース エンジニアリング、デバッグ、改ざんを行うことができます。 Dotfuscator Community Edition (CE) を使用すると、マネージド コードを難読化し、ビルド時に実行時のセキュリティ状態検出コードを Xamarin.Android アプリに挿入して、ルート化されたデバイスでアプリが実行されているかどうかを検出して応答できます。

Dotfuscator CE は Visual Studio 2017 に含まれています。 Dotfuscator を使用するには、[ ツール] > [PreEmptive Protection - Dotfuscator] をクリックします。

Dotfuscator CE を構成するには、「 Xamarin での Dotfuscator Community Edition の使用」を参照してください。 構成が完了すると、Dotfuscator CE によって、作成された各ビルドが自動的に保護されます。

アセンブリをネイティブ コードにバンドルする

このオプションを有効にすると、アセンブリはネイティブ共有ライブラリにバンドルされます。 これにより、アセンブリを圧縮し、より小さい .apk ファイルを許可できます。 アセンブリ圧縮は、難読化の 最小限 の形式も与えます。そのような難読化に頼るべきではありません。

このオプションにはエンタープライズ ライセンスが必要であり、 高速展開の使用 が無効になっている場合にのみ使用できます。 ネイティブ コードへのアセンブリのバンドル は、既定では無効になっています。

[ ネイティブ コードへのバンドル ] オプションは、アセンブリがネイティブ コードにコンパイルされることを意味 しないこと に注意してください。 AOT コンパイルを使用してアセンブリをネイティブ コードにコンパイルすることはできません。

AOT コンパイル

AOT コンパイル オプション ([パッケージ化のプロパティ] ページ) では、アセンブリの事前コンパイル (AOT) が有効になります。 このオプションを有効にすると、ランタイム前にアセンブリをプリコンパイルすることで、Just In Time (JIT) のスタートアップ オーバーヘッドが最小限に抑えられます。 結果のネイティブ コードは、コンパイルされていないアセンブリと共に APK に含まれます。 これにより、アプリケーションの起動時間が短くなりますが、APK サイズが若干大きくなります。

AOT コンパイル オプションには、エンタープライズ ライセンス以上が必要です。 AOT コンパイル は、プロジェクトがリリース モード用に構成されていて、既定で無効になっている場合にのみ使用できます。 AOT コンパイルの詳細については、「 AOT」を参照してください。

LLVM 最適化コンパイラ

LLVM 最適化コンパイラは、より小さく高速なコンパイル済みコードを作成し、AOT コンパイルアセンブリをネイティブ コードに変換しますが、ビルド時間が遅くなります。 LLVM コンパイラは既定で無効になっています。 LLVM コンパイラを使用するには、最初に AOT コンパイル オプションを有効にする必要があります ([ パッケージ化のプロパティ] ページ)。

注

LLVM 最適化コンパイラ オプションには、エンタープライズ ライセンスが必要です。

パッケージ化のプロパティを設定する

パッケージ化プロパティは、次のスクリーンショットに示すように、プロジェクトのプロパティの [Android オプション] セクションで設定できます。

パッケージの特性

これらのプロパティの多く ( [共有ランタイムの使用] や [ 高速配置の使用] など) は、デバッグ モードを対象としています。 ただし、アプリケーションがリリース モード用に構成されている場合、アプリの サイズと実行速度の最適化方法、 改ざんから保護する方法、さまざまなアーキテクチャとサイズ制限をサポートするためにパッケージ化する方法を決定するその他の設定があります。

サポートされているアーキテクチャの指定

Xamarin.Android アプリをリリース用に準備する場合は、サポートされている CPU アーキテクチャを指定する必要があります。 1 つの APK に、複数の異なるアーキテクチャをサポートするマシン コードを含めることができます。 複数 の CPU アーキテクチャの サポートの詳細については、CPU アーキテクチャを参照してください。

選択した ABI ごとに1つのパッケージ（.APK）を生成する

このオプションを有効にすると、サポートされているすべての ABI に対して 1 つの大きな APK ではなく、サポートされている ABI ごとに 1 つの APK が作成されます (CPU アーキテクチャで説明されているように、[詳細設定] タブで選択)。 このオプションは、プロジェクトがリリース モード用に構成されていて、既定で無効になっている場合にのみ使用できます。

Multi-Dex

[Multi-Dex を有効にする] オプションが有効になっている場合、Android SDK ツールを使用して、.dex ファイル形式の 65K メソッド制限をバイパスします。 65K メソッドの制限は、アプリが 参照 する Java メソッドの数 (アプリが依存するライブラリ内のものを含む) に基づいています。 これは、ソース コードで記述されたメソッドの数に基づくものではありません。 アプリケーションが定義するメソッドが数個しかないが、多数の (または大規模なライブラリ) を使用している場合、65K の制限を超える可能性があります。

アプリが、参照されるすべてのライブラリ内のすべてのメソッドを使用していない可能性があります。そのため、ProGuard (上記参照) などのツールで、未使用のメソッドをコードから削除できる可能性があります。 ベスト プラクティスは、必要な場合にのみ Multi-Dex を有効 にすることです。つまり、ProGuard を使用した後でも、アプリは 65,000 を超える Java メソッドを参照します。

Multi-Dex の詳細については、「 64K 以上のメソッドを使用してアプリを構成する」を参照してください。

Android アプリ バンドル

アプリ バンドルは、デバイスに直接デプロイできないため、API とは異なります。 むしろ、コンパイル済みのすべてのコードとリソースと共にアップロードすることを目的とした形式です。 署名済みアプリ バンドルをアップロードすると、Google Play には、アプリケーションの API をビルドして署名し、動的配信を使用してユーザーに提供するために必要なものがすべて揃います。

Android アプリ バンドルのサポートを有効にするには、Android プロジェクト オプション内の Android Package Format プロパティのbundle値にオプトインする必要があります。 これを行う前に、アプリ バンドルがリリース パッケージのみを対象とするため、プロジェクトを Release 構成に変更してください。

これで、アーカイブ フローに従ってアプリ バンドルを生成できるようになりました。 これにより、アプリケーションのアプリ バンドルが生成されます。

Android アプリ バンドルの詳細については、「 Android アプリ バンドル」を参照してください。

コンパイル

上記の手順がすべて完了すると、アプリはコンパイルの準備が整います。 [ ソリューションのビルド > リビルド ] を選択して、リリース モードで正常にビルドされることを確認します。 この手順では APK はまだ生成されないことに注意してください。

アプリ パッケージへの署名 では、パッケージ化と署名について詳しく説明します。

出版用アーカイブ

発行プロセスを開始するには、 ソリューション エクスプローラー でプロジェクトを右クリックし、[ アーカイブ]... コンテキスト メニュー項目を選択します。

アーカイブ アプリ

アーカイブ。。。 は アーカイブ マネージャー を起動し、次のスクリーンショットに示すようにアプリ バンドルをアーカイブするプロセスを開始します。

アーカイブ マネージャー

アーカイブを作成するもう 1 つの方法は、 ソリューション エクスプローラー でソリューションを右クリックし、[ すべてアーカイブ] を選択してソリューションをビルドし、アーカイブを生成できるすべての Xamarin プロジェクトをアーカイブすることです。

すべてアーカイブ

Archive と Archive All の両方で、アーカイブ マネージャーが自動的に起動します。 アーカイブ マネージャーを直接起動するには、[ツール] > [アーカイブ マネージャー]... メニュー項目をクリックします。

アーカイブ マネージャーを起動する

ソリューション のアーカイブ は、ソリューション ノードを右クリックして [ アーカイブの表示] を選択することで、いつでも行うことができます。

アーカイブの表示

アーカイブ マネージャー

アーカイブ マネージャーは、ソリューション一覧ペイン、アーカイブ リスト、および詳細パネルで構成されます。

[アーカイブ マネージャー] ペイン

ソリューション一覧には、少なくとも 1 つのアーカイブ済みプロジェクトを持つすべてのソリューションが表示されます。 ソリューションの一覧には、次のセクションが含まれています。

  • 現在のソリューション – 現在のソリューションを表示します。 現在のソリューションに既存のアーカイブがない場合は、この領域が空になる可能性があることに注意してください。
  • すべてのアーカイブ – アーカイブを持つすべてのソリューションを表示します。
  • 検索 テキスト ボックス (上部) – テキスト ボックスに入力された検索文字列に従って、[ すべてのアーカイブ ] リストに一覧表示されているソリューションをフィルター処理します。

[アーカイブ一覧] には、選択したソリューションのすべてのアーカイブの一覧が表示されます。 アーカイブ リストには、次のセクションが含まれています。

  • 選択したソリューション名 – ソリューション 一覧で選択したソリューションの名前が表示されます。 アーカイブリストに表示されるすべての情報は、この選択したソリューションを参照します。
  • プラットフォーム フィルター – このフィールドを使用すると、プラットフォームの種類 (iOS や Android など) でアーカイブをフィルター処理できます。
  • アーカイブ アイテム – 選択したソリューションのアーカイブの一覧。 この一覧の各項目には、プロジェクト名、作成日、プラットフォームが含まれます。 また、アイテムがアーカイブまたは発行されたときの進行状況などの追加情報を表示することもできます。

詳細パネルには、各アーカイブに関する追加情報が表示されます。 また、ユーザーは配布ワークフローを開始したり、配布が作成されたフォルダーを開いたりすることもできます。 [ビルド コメント] セクションでは、アーカイブにビルド コメントを含めることができます。

流通

アーカイブされたバージョンのアプリケーションを発行する準備ができたら、アーカイブ マネージャーでアーカイブを選択し、[配布]ボタンをクリックします。

[配布] ボタン

[ 配布チャネル ] ダイアログには、アプリに関する情報、配布ワークフローの進行状況の表示、および配布チャネルの選択が表示されます。 最初の実行時には、次の 2 つの選択肢が表示されます。

配布チャネルの選択

次のいずれかの配布チャネルを選択できます。

  • アドホック – 署名された APK を Android デバイスにサイドロードできるディスクに保存します。 引き続き アプリ パッケージへの署名 に進み、Android 署名 ID を作成する方法、Android アプリケーション用の新しい署名証明書を作成する方法、アプリの アドホック バージョンをディスクに発行する方法について説明します。 これは、テスト用の APK を作成する良い方法です。

  • Google Play – 署名された APK を Google Play に公開します。 Google Play ストアで APK に署名して公開する方法については、「 Google Play への 公開」に進んでください。