リリースに向けてアプリケーションを準備する

アプリケーションがコード化され、テストされたら、配信のためにパッケージを用意する必要があります。 このパッケージ準備における最初の作業は、リリース用のアプリケーションをビルドすることです。中心的な作業は、いくつかのアプリケーション属性を設定することです。

次の手順で、リリースに向けてアプリをビルドします。

  • アプリケーションアイコンを指定 する–各 Xamarin Android アプリケーションには、アプリケーションアイコンが指定されている必要があります。 厳密には必須ではありませんが、Google Play など、一部のマーケットでは要求されます。

  • アプリケーションのバージョン 管理-この手順では、バージョン管理情報を初期化または更新します。 これは将来、アプリケーションを更新するために、また、インストールしているアプリケーションのバージョンをユーザーに知らせるために重要です。

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

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

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

  • Compile : コードとアセットをコンパイルして、リリースモードでビルドされていることを確認します。

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

各手順について以下で詳しく説明します。

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

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

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

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

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

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

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

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

Android アプリケーションの保守と配布には、バージョン管理が重要です。 何らかのバージョン管理がなければ、アプリケーションが更新される必要があるかどうか、またはその方法を決定することが困難です。 バージョン管理に役立てるために、Android は次の 2 つの異なる種類の情報を認識します。

  • [バージョン番号] –アプリケーションのバージョンを表す整数値 (Android とアプリケーションで内部的に使用されます)。 ほとんどのアプリケーションは、この値を 1 に設定して開始し、ビルドごとにインクリメントされます。 この値は、バージョン名の属性とは関係ありません (下記参照)。 アプリケーションおよび発行サービスで、この値がユーザーに表示されることはありません。 この値は、 AndroidManifest.xml ファイルにとして格納され ます。

  • バージョン名 –特定のデバイスにインストールされているアプリケーションのバージョンに関する情報をユーザーに伝えるためにのみ使用される文字列。 バージョン名は、ユーザーまたは Google Play 内に表示されることを意図しています。 この文字列は、Android によって内部的に使用されることはありません。 バージョン名は、ユーザーが自分のデバイスにインストールされているビルドを識別するために役立つ文字列の値になります。 この値は、 AndroidManifest.xml ファイルにとして格納され ます。

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

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

APK を圧縮する

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

リンカーを構成する

リリース モードでは、アプリケーションがランタイムで必要な Xamarin.Android の要素のみを送付するように、共有ランタイムはオフにし、リンクをオンにします。 Xamarin.Android のリンカーでは、スタティック分析を使用して、Xamarin.Android アプリケーションによって使用または参照されるアセンブリ、型、および型メンバーを決定します。 次に、リンカーは、使用 (または参照) されないすべての未使用のアセンブリ、型、メンバーを破棄します。 この操作を行うと、パッケージ サイズが大幅に削減されます。 たとえば、HelloWorld の例を検討します。この例では、APK の最終的なサイズが 83% 削減されます。

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

  • 構成: SDK アセンブリのみ– 4.2.5 Size = 3.0 MB。

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

リンカーオプション

[リンク中] プルダウン メニューには、リンカーを制御するために、次のオプションが用意されています。

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

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

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

リンクは意図しない副作用を起すことがあります。そのため、リリース モードで、かつ、物理デバイス上でアプリケーションを再テストすることが重要です。

ProGuard

ProGuard は、Java コードをリンクし、難読化する Android SDK ツールです。 ProGuard は通常、APK の大きな組み込みライブラリ (Google Play サービスなど) のフットプリントを少なくすることで小さなアプリケーションを作成するために使用します。 ProGuard では、未使用の Java バイトコードが削除されるため、結果としてアプリが小さくなります。 たとえば、小さな Xamarin で ProGuard を使用すると、Android アプリでは通常、サイズが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 が難読化されることはなく、さらにはカスタム構成ファイルでも難読化されることはありません。 難読化を使用する場合は「Application Protection with Dotfuscator」(Dotfuscator を使用したアプリケーションの保護) を参照してください。

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

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

デバッグを無効にする

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

重要

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

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

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

デバッグ ビルドでは、デバッグしやすいように、自動的にアクセス許可が設定されることに注意してください (InternetReadExternalStorage など)。 ただし、リリース ビルドでは、明示的に設定したアクセス許可のみを使用します。 リリース ビルドへの切り替えによって、使用しているアプリがデバッグ ビルドで使用可能であったアクセス許可を失う場合は、アクセス許可で示されているように、必要なアクセス許可リストのアクセス許可を明示的に有効にしていることを確認します。

Dotfuscator によるアプリケーションの保護

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

Dotfuscator CE は Visual Studio 2017 と共にインストールされます。 Dotfuscator を使用するには、[ ツール ] [PreEmptive Protection - Dotfuscator] をクリックします

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

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

このオプションが有効になっていると、アセンブリがネイティブの共有ライブラリにまとめられます。 これにより、アセンブリを圧縮し、より小さな .apk ファイルを許可することができます。 アセンブリの圧縮により、"最小限の" 形式の難読化も可能になります。このような難読化には、依存しないようにする必要があります。

このオプションは Enterprise ライセンスを必要とし、 [Fast Deployment の使用] が無効になっている場合にのみ使用できます。 [ネイティブ コードへのアセンブリのバンドル] は既定では無効です。

[Bundle into Native Code]\(ネイティブ コードへのバンドル\) オプションは、アプリケーションがネイティブ コードにコンパイルされることを意味するわけではありませんAOT コンパイルを使用して、アセンブリをネイティブ コードにコンパイルすることはできません。

AOT コンパイル

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

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

LLVM 最適化コンパイラ

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

Note

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

パッケージング プロパティを設定する

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

パッケージのプロパティ

[共有ランタイムの使用][Fast Deployment の使用] など、プロパティの多くはデバッグ モードを意図しています。 ただし、リリース モードのためにアプリケーションを構成するとき、サイズと実行速度に関してアプリを最適化する方法、改ざんを防止する方法、さまざまなアーキテクチャやサイズ制約に対応できるようにパッケージ化する方法を決定する設定が他にあります。

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

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

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

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

Multi-Dex

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

参照されるすべてのライブラリのすべてのメソッドをアプリが使用していない場合があるため、ProGuard (上記参照) などのツールを使用して、未使用のメソッドをコードから削除することができます。 [Multi-Dex を有効にする] は本当に必要な場合にのみ有効にすることをお勧めします。たとえば、ProGuard を使用してもアプリが 65K を超える Java メソッドを参照する場合などです。

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

Android App Bundle

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

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

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

Android App Bundle の詳細については、「Android App Bundle について」を参照してください。

Compile

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

アプリ パッケージの署名に関するセクションでは、パッケージ化と署名についてさらに詳しく説明します。

発行のためのアーカイブ

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

アーカイブ アプリ

[アーカイブ...] を選択すると、アーカイブ マネージャーが起動し、このスクリーン ショットに示すように、アプリ バンドルをアーカイブするプロセスが開始されます。

アーカイブ マネージャー

アーカイブを作成する別の方法として、ソリューション エクスプローラーでソリューションを右クリックし、 [すべてアーカイブ] を選択します。これにより、ソリューションがビルドされ、アーカイブを生成できるすべての Xamarin プロジェクトがアーカイブされます。

すべてアーカイブ

[アーカイブ][すべてアーカイブ] のどちらも、アーカイブ マネージャーを自動的に起動します。 アーカイブマネージャーを直接起動するには、[ツール] [ archive manager... ] メニュー項目をクリックします。

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

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

アーカイブの表示

アーカイブ マネージャー

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

アーカイブマネージャーのウィンドウ

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

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

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

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

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

配布

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

[配布] ボタン

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

配布チャネルの選択

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

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

  • Google Play –署名された apk を Google Play に発行します。 引き続き「Google Play に公開する」に進み、APK を署名して Google Play ストアに発行する方法について学習してください。