リリースに向けてアプリケーションを準備する
アプリケーションがコード化され、テストされたら、配信のためにパッケージを用意する必要があります。 このパッケージ準備における最初の作業は、リリース用のアプリケーションをビルドすることです。中心的な作業は、いくつかのアプリケーション属性を設定することです。
次の手順で、リリースに向けてアプリをビルドします。
アプリケーション アイコンを指定する - Xamarin.Android アプリケーションごとにアプリケーション アイコンを指定する必要があります。 厳密には必須ではありませんが、Google Play など、一部のマーケットでは要求されます。
アプリケーションをバージョン管理する - この手順では、バージョン管理情報を初期化または更新します。 これは将来、アプリケーションを更新するために、また、インストールしているアプリケーションのバージョンをユーザーに知らせるために重要です。
APK を圧縮する - マネージド コードで Xamarin.Android リンカーを使用し、Java バイトコードで ProGuard を使用すると、最終的な APK のサイズを大幅に縮小できます。
アプリケーションを保護する - ユーザーや攻撃者によるアプリケーションのデバッグ、改ざん、またはリバース エンジニアリングを防ぐために、デバッグを無効化し、マネージド コードを難読化し、アンチデバッグと改ざん防止を追加し、ネイティブ コンパイルを使用します。
パッケージング プロパティを設定する - パッケージング プロパティは、Android アプリケーション パッケージ (APK) の作成を制御します。 この手順は APK を最適化し、そのアセットを保護し、必要に応じてパッケージをモジュール化します。 さらに、デバイス用に最適化された Android App Bundle をユーザーに提供することもできます。
コンパイルする - この手順ではコードとアセットをコンパイルし、リリース モードでビルドされることを確認します。
発行用にアーカイブ - この手順では、アプリをビルドし、署名および発行用にアーカイブへ配置します。
各手順について以下で詳しく説明します。
各 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 に設定して開始し、ビルドごとにインクリメントされます。 この値は、バージョン名の属性とは関係ありません (下記参照)。 アプリケーションおよび発行サービスで、この値がユーザーに表示されることはありません。 この値は、AndroidManifest.xml ファイルに
android:versionCodeとして保存されます。バージョン名 - (特定のデバイスにインストールされる) アプリケーションのバージョンに関連する情報をユーザーに知らせるためだけに使用される文字列。 バージョン名は、ユーザーまたは Google Play 内に表示されることを意図しています。 この文字列は、Android によって内部的に使用されることはありません。 バージョン名は、ユーザーが自分のデバイスにインストールされているビルドを識別するために役立つ文字列の値になります。 この値は、AndroidManifest.xml ファイルに
android:versionNameとして保存されます。
Visual Studio では、次のスクリーンショットで示すように、これらの値は、プロジェクトの [プロパティ] の [Android マニフェスト] セクションで設定できます。
不要なマネージド コードを削除する Xamarin.Android リンカーと、使用しない Java バイトコードを削除する Android SDK の ProGuard ツールを組み合わせることで、Xamarin.Android APK を小さくすることができます ビルド プロセスでは最初に Xamarin.Android リンカーを使用してマネージド (C#) コード レベルでアプリを最適化し、次に ProGuard (有効になっている場合) を使用して Java バイトコード レベルで APK を最適化します。
リリース モードでは、アプリケーションがランタイムで必要な Xamarin.Android の要素のみを送付するように、共有ランタイムはオフにし、リンクをオンにします。 Xamarin.Android のリンカーでは、スタティック分析を使用して、Xamarin.Android アプリケーションによって使用または参照されるアセンブリ、型、および型メンバーを決定します。 次に、リンカーは、使用 (または参照) されないすべての未使用のアセンブリ、型、メンバーを破棄します。 この操作を行うと、パッケージ サイズが大幅に削減されます。 たとえば、HelloWorld の例を検討します。この例では、APK の最終的なサイズが 83% 削減されます。
構成: なし - 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 は、Java コードをリンクし、難読化する Android SDK ツールです。 ProGuard は通常、APK の大きな組み込みライブラリ (Google Play サービスなど) のフットプリントを少なくすることで小さなアプリケーションを作成するために使用します。 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 が難読化されることはなく、さらにはカスタム構成ファイルでも難読化されることはありません。 難読化を使用する場合は「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
デバッグ ビルドでは、デバッグしやすいように、自動的にアクセス許可が設定されることに注意してください (Internet、ReadExternalStorage など)。 ただし、リリース ビルドでは、明示的に設定したアクセス許可のみを使用します。 リリース ビルドへの切り替えによって、使用しているアプリがデバッグ ビルドで使用可能であったアクセス許可を失う場合は、アクセス許可で示されているように、必要なアクセス許可リストのアクセス許可を明示的に有効にしていることを確認します。
デバッグが無効になっていても、攻撃者が、アプリケーションを再パッケージ化し、構成オプションまたはアクセス許可を追加または削除することは可能です。 これにより、攻撃者がアプリケーションをリバース エンジニアリング、デバッグ、または改ざんすることができます。 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 コンパイル] オプション ([パッケージング プロパティ] ページ) により、アセンブリの Ahead Of Time (AOT) コンパイルが有効になります。 このオプションを有効にすると、ランタイム前にアセンブリがプリコンパイルされることで Just In Time (JIT) スタートアップのオーバーヘッドが最小化します。 生成されたネイティブ コードは、コンパイルされていないアセンブリと共に APK に含まれています。 この結果、アプリケーションの起動時間が短縮しますが、APK のサイズが少し大きくなります。
[AOT コンパイル] オプションには、Enterprise 以上のライセンスが必要です。 [AOT コンパイル] は、プロジェクトがリリース モードで構成されていて、これが既定で無効になっている場合にのみ使用できます。 AOT コンパイルの詳細については、「AOT」を参照してください。
LLVM 最適化コンパイラでは、より小さく高速なコンパイル済みコードを作成し、AOT コンパイルによるアセンブリをネイティブ コードに変換しますが、その分ビルド時間がかかります。 LLVM コンパイラは既定では無効です。 LLVM コンパイラを使用するには、最初に ([パッケージング プロパティ] ページで) [AOT コンパイル] オプションを有効にする必要があります。
注意
LLVM 最適化コンパイラ オプションには、エンタープライズ ライセンスが必要です。
パッケージング プロパティは、次のスクリーンショットで示すように、プロジェクトの [プロパティ] の [Android オプション] セクションで設定できます。
[共有ランタイムの使用] や [Fast Deployment の使用] など、プロパティの多くはデバッグ モードを意図しています。 ただし、リリース モードのためにアプリケーションを構成するとき、サイズと実行速度に関してアプリを最適化する方法、改ざんを防止する方法、さまざまなアーキテクチャやサイズ制約に対応できるようにパッケージ化する方法を決定する設定が他にあります。
リリースに向けて Xamarin.Android アプリを準備しているときに、サポートされる CPU アーキテクチャを指定する必要があります。 1 つの APK に、複数の異なるアーキテクチャをサポートするためのマシン コードを含めることができます。 複数の CPU アーキテクチャのサポートに関する詳細については、「CPU アーキテクチャ」を参照してください。
このオプションが有効になっていると、サポートされるすべての ABI を対象とする単一の大きな APK ではなく、サポートされるそれぞれの ABI ( [詳細設定] タブで選択。「CPU Architectures」(CPU アーキテクチャ) に説明あり) に対して 1 つの APK が作成されます。 このオプションは、プロジェクトがリリース モードで構成されていて、これが既定で無効になっている場合にのみ使用できます。
[Multi-Dex を有効にする] オプションが有効になっていると、Android SDK ツールを使用して .dex ファイル形式の 65K のメソッド制限が回避されます。 65K のメソッド制限は、アプリが "参照する" Java メソッドの数に基づいています (アプリが依存しているすべてのライブラリのメソッドも含む)。"ソース コードに記述されている" メソッドの数には基づいていません。 アプリケーションで定義しているメソッドの数が 2、3 個で、使用するメソッドが多い (またはライブラリが大きい) 場合、65K の制限を超過する可能性があります。
参照されるすべてのライブラリのすべてのメソッドをアプリが使用していない場合があるため、ProGuard (上記参照) などのツールを使用して、未使用のメソッドをコードから削除することができます。 [Multi-Dex を有効にする] は本当に必要な場合にのみ有効にすることをお勧めします。たとえば、ProGuard を使用してもアプリが 65K を超える Java メソッドを参照する場合などです。
Multi-Dex の詳細については、「64K を超えるメソッドを使用するアプリの設定」を参照してください。
App Bundle は、デバイスに直接配置できないため、APK とは異なります。 この形式は、コンパイル済みのすべてのコードとリソースと共にアップロードすることを目的としています。 署名済みアプリ バンドルをアップロードすると、アプリケーションの APK をビルドして署名し、動的配信を使用してユーザーに提供するために必要なすべてのものが Google Play に与えられます。
Android App Bundle のサポートを有効にするには、Android プロジェクト オプション内の [Android パッケージ形式] プロパティの bundle 値をオプトインする必要があります。 アプリ バンドルはリリース パッケージのみを対象としているため、これを行う前に、プロジェクトを必ず Release 構成に変更してください。
これで、アーカイブ フローに従って、アプリ バンドルを生成できるようになりました。 これで、アプリケーションのアプリ バンドルが生成されます。
Android App Bundle の詳細については、「Android App Bundle について」を参照してください。
上記の手順のすべてが完了したら、アプリのコンパイルの準備ができます。 [ビルド] > [ソリューションのリビルド] を選び、リリース モードで正常にビルドされることを確認します。 この手順ではまだ APK が生成されません。
アプリ パッケージの署名に関するセクションでは、パッケージ化と署名についてさらに詳しく説明します。
発行プロセスを開始するには、ソリューション エクスプローラーでプロジェクトを右クリックし、 [アーカイブ] コンテキスト メニュー項目を選択します。
[アーカイブ...] を選択すると、アーカイブ マネージャーが起動し、このスクリーン ショットに示すように、アプリ バンドルをアーカイブするプロセスが開始されます。
アーカイブを作成する別の方法として、ソリューション エクスプローラーでソリューションを右クリックし、 [すべてアーカイブ] を選択します。これにより、ソリューションがビルドされ、アーカイブを生成できるすべての Xamarin プロジェクトがアーカイブされます。
[アーカイブ] と [すべてアーカイブ] のどちらも、アーカイブ マネージャーを自動的に起動します。 アーカイブ マネージャーを直接起動するには、[ツール] > [アーカイブ マネージャー] メニュー項目を選びます。
[ソリューション] ノードを右クリックして [アーカイブの表示] を選択することで、いつでもソリューションをアーカイブすることができます。
アーカイブ マネージャーは、ソリューション一覧ウィンドウ、アーカイブ一覧、および詳細パネルで構成されます。
ソリューション一覧には、アーカイブされた少なくとも 1 つのプロジェクトを持つすべてのソリューションが表示されます。 ソリューション一覧には、次のセクションが含まれます。
- 現在のソリューション - 現在のソリューションが表示されます。 現在のソリューションに既存のアーカイブがない場合は、この領域は空になる可能性があることに注意してください。
- すべてのアーカイブ - アーカイブがあるすべてのソリューションが表示されます。
- [検索] テキストボックス (上部) - テキストボックスに入力された検索文字列に従って [すべてのアーカイブ] 一覧に表示されるソリューションにフィルターを適用します。
アーカイブ一覧には、選択したソリューションのすべてのアーカイブの一覧が表示されます。 アーカイブ一覧には、次のセクションが含まれます。
- 選択したソリューション名 - ソリューション一覧で選んだソリューションの名前が表示されます。 アーカイブ一覧に表示されるすべての情報は、この選択したソリューションを参照しています。
- プラットフォーム フィルター - このフィールドにより、プラットフォームの種類 (iOS、Android など) ごとにアーカイブをフィルター処理できます。
- アーカイブ項目 - 選んだソリューションのアーカイブ一覧です。 この一覧内の各項目には、プロジェクト名、作成日、およびプラットフォームが含まれています。 項目がアーカイブまたは発行されているときの進行状況などの追加情報も表示できます。
詳細パネルには、各アーカイブに関する追加情報が表示されます。 ユーザーが、配布ワークフローを開始したり、またはディストリビューションが作成されたフォルダーを開いたりすることもできます。 [ビルドのコメント] セクションにより、アーカイブにビルドのコメントを含めることができます。
アーカイブ済みのバージョンのアプリケーションを発行する準備ができたら、アーカイブ マネージャーでアーカイブを選択し、 [配布] ボタンをクリックします。
[配布チャネル] ダイアログには、アプリに関する情報、配布ワークフローの進行状況を示す値、および配布チャネルの選択肢が表示されます。 最初の実行時に、2 つの選択肢が表示されます。
次の配布チャネルのいずれかを選択できます。
アドホック - Android デバイスにサイドロードできるように、署名済み APK をディスクに保存します。 引き続きアプリ パッケージの署名に関するセクションに進み、Android の署名 ID を作成する方法、Android アプリケーション用の新しい署名証明書を作成する方法、アプリのアドホック バージョンをディスクに発行する方法を学習してください。 これは、テスト用の APK を作成するための効果的な方法です。
Google Play - 署名済み APK を Google Play に発行します。 引き続き「Google Play に公開する」に進み、APK を署名して Google Play ストアに発行する方法について学習してください。
