アプリを Google Play に公開する場合は、Android App Bundle を作成してアップロードしてください。そうすることで、各ユーザーのデバイス構成に合わせて最適化された APK が Google Play によって自動的に生成、配信されるため、ユーザーはアプリの実行に必要なコードとリソースをダウンロードするだけで済みます。複数の APK を公開するという方法は、Google Play に公開しない場合は便利ですが、各 APK のビルド、署名、管理を自分で行う必要があります。
Android アプリを開発して Google Play で複数の APK を利用する場合は、最初からおすすめの方法を採用し、開発プロセスで不必要な問題が生じないようにすることが重要です。このレッスンでは、アプリの APK を複数作成する方法について説明します。各 APK は、わずかに異なる範囲の API レベルに対応しています。また、複数 APK のコードベースをできるだけ簡単に管理するために必要なツールも紹介します。
複数 APK の必要性を確認する
複数の世代の Android プラットフォームで動作するアプリを作成するときは、下位互換性を犠牲にすることなく、新しいデバイスの新機能を利用することが適切です。最初は複数 APK のサポートが最良の解決策であるかのように思えるかもしれませんが、多くの場合、そうではありません。複数 APK のデベロッパー ガイドの単一 APK の代わりに単一 APK を使用するセクションには、単一の APK でこれを実現する方法（サポート ライブラリの使用など）に関する有用な情報が記載されています。また、 こちらの記事のリフレクションなどの計算コストの高い手法に頼らずに、1 つの APK で特定の API レベルでのみ実行されるコードを記述する方法についても説明します。
アプリを 1 つの APK に制限することで、APK を管理できる場合、次のような利点があります。
- 公開とテストがより簡単になります
- 管理するコードベースは 1 つだけです
- アプリはデバイス構成の変更に適応できます
- 複数のデバイスにまたがるアプリの復元が機能します
- 市場における好み、ある APK から次の APK への「アップグレード」の動作、どの APK がどのクラスのデバイスに対応するかを気にする必要はありません。
このレッスンの残りの部分では、このトピックについて調査し、リンクされたリソースにしっかりと内容を取り込んで、複数の APK がアプリに適していると判断したことを前提としています。
要件を図示する
まず、簡単なグラフを作成して、必要な APK の数と各 APK がカバーする API 範囲をすぐに確認します。Android デベロッパー ウェブサイトのプラットフォーム バージョンのページでは、特定のバージョンの Android プラットフォームを搭載しているアクティブなデバイスの相対数に関するデータを確認できます。また、最初は簡単に思えますが、各 APK がどの API レベルのセットをターゲットにするかを管理するのは、特に重複が発生する場合（多くの場合に重複が発生する場合）はすぐに困難になります。幸いなことに、要件をすばやく簡単にまとめ、後で簡単に参照できます。
複数 APK チャートを作成するには、Android プラットフォームのさまざまな API レベルを表すセルの行を最初に記述します。Android の将来のバージョンを表す追加のセルを末尾にスローします。
| 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | + |
次に、個々の APK を表す色をセルに塗ります。以下に、各 APK を特定の範囲の API レベルに適用する方法の一例を示します。
| 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | + |
この図が完成したら、チームに配布します。「API レベル 3 ～ 6 の APK はどうなってるの？うまくいってる？」と尋ねる代わりに、「Blue APK はどうやって来るの？」と尋ねるだけです。
ライブラリ プロジェクトにすべての共通のコードとリソースを配置する
既存の Android アプリを変更する場合でも、アプリをゼロから始める場合でも、これはコードベースに対して最初に行うことであり、最も重要なことです。ライブラリ プロジェクトに含まれるものはすべて 1 回更新するだけで済みます（言語がローカライズされた文字列、カラーテーマ、共有コードで修正されるバグなどを考慮してください）。これにより、開発時間を短縮し、簡単に回避できたミスの可能性を低減できます。
注: ライブラリ プロジェクトを作成してインクルードする方法の実装の詳細はこのレッスンでは扱いませんが、Android ライブラリを作成するを読むと迅速に確認できます。
既存のアプリを変換して複数の APK をサポートする場合は、ローカライズされたすべての文字列ファイル、値のリスト、テーマの色、メニュー アイコン、レイアウト（APK 間で変更されないもの）をコードベースで調べて、すべてをライブラリ プロジェクトに入れます。あまり変更しないコードも ライブラリプロジェクトに配置してくださいこれらのクラスを拡張して、APK から APK に 1 つか 2 つのメソッドを追加することになるでしょう。
一方、アプリをゼロから作成する場合は、最初に可能な限りコードをライブラリ プロジェクトで記述してから、必要な場合にのみ個々の APK に移動するようにしてください。この blob を 1 つの blob に追加し、次に別の blob に追加してから数か月後に、この blob をライブラリ セクションに移動できるかどうかを判断するよりも、長い目で見れば管理がはるかに簡単です。
新しい APK プロジェクトを作成する
リリースする APK ごとに別個の Android プロジェクトが必要です。ライブラリ プロジェクトと関連するすべての APK プロジェクトを同じ親フォルダに配置すると、簡単に整理できます。 また、各 APK は同じパッケージ名である必要がありますが、必ずしもパッケージ名をライブラリと共有する必要はありません。前述のスキームに従って 3 つの APK を使用する場合、ルート ディレクトリは次のようになります。
alexlucas:~/code/multi-apks-root$ ls foo-blue foo-green foo-lib foo-red
プロジェクトを作成したら、ライブラリ プロジェクトを各 APK プロジェクトへの参照として追加します。可能であれば、ライブラリ プロジェクトで開始アクティビティを定義し、APK プロジェクトでそのアクティビティを拡張します。ライブラリ プロジェクトで開始アクティビティを定義すると、アプリの初期化をすべて 1 か所にまとめることができます。それにより、アナリティクスの初期化、ライセンス チェックの実行、APK 間でほとんど変更されないその他の初期化手順といった「汎用的」なタスクを、個々の APK に再実装する必要がなくなります。
マニフェストを調整する
複数の APK を使用するアプリをユーザーが Google Play からダウンロードする場合、次の 2 つの単純なルールを使用して、使用する適切な APK が選択されます。
- マニフェストで特定の APK が適格であることが示されている必要がある
- 適格な APK のうち、バージョン番号が最も大きいものが優先される
たとえば、前述した複数の APK のセットを考えてみましょう。どの APK の最大 API レベルも設定していないと仮定します。各 APK の可能な範囲を個別に考えると、次のようになります。
| 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | + |
| 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | + |
| 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | + |
minSdkVersion の値が大きい APK はより高いバージョン コードを持つ必要があるため、versionCode の値に関しては赤 ≥ 緑 ≥ 青であることがわかります。したがって、結果的にこの図は次のように簡略化できます。
| 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | + |
ここで、赤の APK には他の 2 つには適用されない要件があると仮定します。 考えられる問題の原因の一覧については、Android デベロッパー ガイドの Google Play でのフィルタのページをご覧ください。たとえば、赤色には前面カメラが必要だとします。実際のところ、赤色の APK の要点は、前面カメラと、API 11 で追加された新機能を組み合わせることです。しかし、実のところ、API 11 をサポートするすべてのデバイスに前面カメラが搭載されているわけではありません。最悪だ！
幸い、ユーザーがそのようなデバイスから Google Play を閲覧している場合、Google Play はマニフェストを確認し、Red が前面カメラを要件としてリストしていることを確認し、Red とそのデバイスがデジタル天国に一致しないと判断した後は静かに無視します。これにより、Green は API 11 を搭載したデバイスと上位互換性があるだけでなく（maxSdkVersion が定義されていないため）、前面カメラの有無も考慮していないことがわかります。ユーザーは、引き続き Google Play からアプリをダウンロードできます。これは、前面カメラ全体に不具合があったものの、その API レベルをサポートする APK がまだ存在していたためです。
すべての APK を別々の「トラック」に保存するには、適切なバージョン コード スキームを使用することが重要です。推奨されるバージョンは、デベロッパー ガイドのバージョン コードのセクションに記載されています。APK のサンプルセットでは、考えられる 3 つのディメンションのいずれか 1 つしか扱っていないため、各 APK を 1,000 単位で区切り、最初の 2 桁をその APK の minSdkVersion に設定して、そこから増分すれば十分です。次に例を示します。
青: 03001, 03002, 03003, 03004...
緑: 07001、07002、07003、07004...
赤:11001、11002、11003、11004...
まとめると、Android マニフェストは次のようになります。
青:
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
android:versionCode="03001" android:versionName="1.0" package="com.example.foo">
<uses-sdk android:minSdkVersion="3" />
...
緑:
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
android:versionCode="07001" android:versionName="1.0" package="com.example.foo">
<uses-sdk android:minSdkVersion="7" />
...
赤:
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
android:versionCode="11001" android:versionName="1.0" package="com.example.foo">
<uses-sdk android:minSdkVersion="11" />
...
リリース前チェックリストを確認する
Google Play にアップロードする前に、次の項目を念入りにチェックしてください。次に示すのは複数 APK と特に関連の深い項目であり、Google Play にアップロードするすべてのアプリ用の完全なチェックリストではないことにご注意ください。
- すべての APK は同じパッケージ名を持つ必要があります
- すべての APK は同じ証明書で署名する必要があります
- プラットフォーム バージョンで APK が重複している場合、minSdkVersion が大きい APK の方が、大きいバージョン コードを持つ必要があります
- マニフェスト フィルタを念入りにチェックして競合する情報がないことを確認します（Cupcake バージョンの特大画面のみをサポートする APK は誰も見ることができません）
- 各 APK のマニフェストは、サポートされる画面、OpenGL のテクスチャ、プラットフォーム バージョンのうち、少なくとも 1 つで一意であることが必要です
- 1 台以上のデバイスで各 APK をテストします。それとは別に、開発マシンには、業界で最もカスタマイズしやすいデバイス エミュレータの 1 つが搭載されています。ぜひ利用してください。
また、市場に投入する前にコンパイル済み APK を検査して、Google Play にアプリの公開を妨げてしまわないようにすることもおすすめします。aapt を使うと簡単です。Aapt（Android Asset Packaging Tool）は、Android アプリの作成とパッケージ化を行うビルドプロセスの一部であり、アプリの検査に非常に便利なツールでもあります。
>aapt dump badging package: name='com.example.hello' versionCode='1' versionName='1.0' sdkVersion:'11' uses-permission:'android.permission.SEND_SMS' application-label:'Hello' application-icon-120:'res/drawable-ldpi/icon.png' application-icon-160:'res/drawable-mdpi/icon.png' application-icon-240:'res/drawable-hdpi/icon.png' application: label='Hello' icon='res/drawable-mdpi/icon.png' launchable-activity: name='com.example.hello.HelloActivity' label='Hello' icon='' uses-feature:'android.hardware.telephony' uses-feature:'android.hardware.touchscreen' main supports-screens: 'small' 'normal' 'large' 'xlarge' supports-any-density: 'true' locales: '--_--' densities: '120' '160' '240'
aapt の出力を調べるときは、supports-screens と compatible-screens の値が競合していないこと、マニフェストで設定した権限の結果として追加された意図しない「uses-feature」値がないことを確認してください。上記の例では、APK は多くのデバイスに表示されません。
その原因は、必要な SEND_SMS 権限の追加により、android.hardware.telephony の機能要件が暗黙的に追加されたことにあります。API 11 は Honeycomb（タブレット用に最適化された Android のバージョン）であり、Honeycomb デバイスにはテレフォニー ハードウェアが含まれていないため、Google Play は、API レベルが高くテレフォニー ハードウェアを備えた今後のデバイスが登場するまで、すべてのケースでこの APK を除外します。
幸いにも、上記の問題は、マニフェストに次の行を追加すれば簡単に解決できます。
<uses-feature android:name="android.hardware.telephony" android:required="false" />
また、android.hardware.touchscreen 要件も暗黙的に追加されます。タッチスクリーンがないデバイスの TV で APK を表示するには、マニフェストに次の行を追加する必要があります。
<uses-feature android:name="android.hardware.touchscreen" android:required="false" />
リリース前チェックリストの確認が完了したら、Google Play に APK をアップロードします。Google Play を閲覧したときにアプリが表示されるまで少し時間がかかることがあります。表示されたら、最後にもう一度チェックを行います。APK が目的のデバイスをターゲットにしていることを確認するため、該当のテストデバイスにアプリをダウンロードします。これで完了です。