アプリを Google Play に公開する場合は、Android App Bundle を作成してアップロードしてください。そうすることで、各ユーザーのデバイス構成に合わせて最適化された APK が Google Play によって自動的に生成、配信されるため、ユーザーはアプリの実行に必要なコードとリソースをダウンロードするだけで済みます。複数の APK を公開するという方法は、Google Play に公開しない場合は便利ですが、各 APK のビルド、署名、管理を自分で行う必要があります。
Android アプリを開発して Google Play の複数の APK を利用する場合は、 最初から適切な方法を採用して 不必要な頭痛の種を防ぐことが重要 開発プロセスに進みますこのレッスンでは、アプリの APK を複数作成し、各 APK で異なるクラスの画面サイズをカバーする方法を説明します。また、複数 APK のコードベースをできるだけ効率的に管理するために必要なツールも紹介します。
複数 APK の必要性を確認する
さまざまな Android デバイスで動作するアプリを作成する場合、個々のデバイスでアプリの外観が最適になるようにしたいはずです。目標 新しい Android API を使用して、大画面のスペースを活かしながら小さな画面でも作業できるようにする 最新のデバイスで使用できる機能や視覚的テクスチャを使用できるが、古いデバイスの使用はやめておく。かもしれない 複数 APK のサポートが最善のソリューションに見えますが、 あります。 複数 APK ガイドの「単一 APK」セクションに、 Google のサポート ライブラリの使用を含め、これらすべてを単一の APK で実現できます。 Android デベロッパー ガイド内のリソースへのリンクも記載しています。
管理できる場合、アプリを単一の APK に制限することには、いくつかの利点があります。 含まれます。
- 公開とテストがより簡単になります
- 管理するコードベースは 1 つだけです
- アプリはデバイス構成の変更に適応できます
- 複数のデバイスにまたがるアプリの復元が機能します
- 市場選好や「アップグレード」による行動を心配する必要がないを 1 つの APK から どの APK をどのクラスのデバイスに適用するか
このレッスンの残りの部分は、トピックについて調査し、 リンク先のリソースのマテリアルにあり、複数の APK がアプリのパスとして適切であると判断されました。 説明します。
要件を図示する
まず簡単なグラフを作成して、必要な APK の数と画面数をすばやく判断しましょう。 サイズ。要件の図は短時間で簡単に作成でき、後で手軽に参照できるので便利です。たとえば、APK を API と API の 2 つのディメンション 画面サイズを選択します取り得る値のペアごとに行と列があり、色が入ったテーブルを作成する それぞれの色が 1 つの APK を表す。
| 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | + | |
| 小 | |||||||||||
| 標準 | |||||||||||
| 大 | |||||||||||
| 特大 |
上記の図は、APK を 4 つに分ける場合の例です。青はすべての小画面 / 標準画面デバイス用、緑は大画面デバイス用、赤は特大画面デバイス用で、いずれも API の範囲は 3 から 10 です。紫色は 特殊なケースで、すべての画面サイズに適用されますが、API 11 以降のみが対象となります。さらに重要なのは、 このグラフを見ると、特定の API と画面サイズの組み合わせに対応する APK がすぐにわかります。また、各 APK を簡潔なコードネームで呼ぶと、伝達もスムーズになります。「Xoom で赤をテストしたよね？」の方が、「Xoom で 3 から 10 対応の特大画面 APK をテストしたよね？」よりはるかに簡単です。この図をプリントアウトして、コードベースの作業に従事するすべての人に渡します。そうすれば、仕事がずっと楽になります。
ライブラリ プロジェクトにすべての共通のコードとリソースを配置する
既存の Android アプリを変更する場合でも、ゼロから作成する場合でも、 コードベースに対してまず行うべきであり 圧倒的に最も重要なことですすべて 更新が必要なのは 1 回だけです（言語にローカライズされた文字列、 カラーテーマ、共有コードのバグ修正）により、開発時間を短縮し、 間違いの可能性が高まります。
注: 作成方法と作成方法の実装の詳細は、 このレッスンでは説明しませんが、インクルード ライブラリの Android ライブラリを作成するをご覧ください。
既存のアプリを変換して複数 APK のサポートに使用する場合は、ローカライズされたすべての文字列ファイル、値のリスト、テーマの色、メニュー アイコン、APK 全体で変更されないレイアウトをコードベースで調べて、それらをすべてライブラリ プロジェクトに配置します。あまり変更されないコードは 共有することもできます。そうしたクラスを拡張して、APK ごとにメソッドを 1 つか 2 つ追加できます。
一方、アプリケーションをゼロから作成する場合は、 まずライブラリ プロジェクトにコードを書き、 できます。長期的に見ると管理がはるかに容易です そして数か月後に、この blob を上に移動できるかどうかを突き止めようとしています。 ライブラリ セクションに移動できます。
新しい APK プロジェクトを作成する
リリースする APK ごとに別個の Android プロジェクトが必要です。簡単に ライブラリ プロジェクトとすべての関連する APK プロジェクトを同じ親フォルダに配置します。 また、各 APK のパッケージ名は同じである必要がありますが、必ずしも同じではありません。 パッケージ名をライブラリと共有する必要があります。このスキームに従って 3 つの APK が存在する場合 ルート ディレクトリは次のようになります。
alexlucas:~/code/multi-apks-root$ ls foo-blue foo-green foo-lib foo-purple foo-red
プロジェクトを作成したら、ライブラリ プロジェクトを各 APK プロジェクトへの参照として追加します。条件 ライブラリ プロジェクトで開始アクティビティを定義し、APK でそのアクティビティを拡張する できます。ライブラリ プロジェクトで開始アクティビティを定義すると、すべてのアプリの初期化を 1 か所にまとめることができるため、個々の APK でアナリティクスの初期化、ライセンス チェックの実行、APK 間であまり変更されないその他の初期化手順などの「ユニバーサル」タスクを再実装する必要がなくなります。
マニフェストを調整する
ユーザーが複数 APK を使用するアプリを Google Play でダウンロードする場合、次の 2 つの単純なルールで適切な APK が選択されます。
- マニフェストで特定の APK が適格であることが示されている必要がある
- 適格な APK のうち、バージョン番号が最も大きいものが優先される
例として、前述の複数 APK のセットについて考えてみましょう。各 APK は 「ターゲット」より大きいすべての画面サイズをサポートするように APK が設定されていますあります。それでは 次のサンプルチャートを使用します。
| 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | + | |
| 小 | |||||||||||
| 標準 | |||||||||||
| 大 | |||||||||||
| 特大 |
カバレッジが重なっても構わないので、各 APK のカバー範囲は次のように記述できます。 次のようになります。
- 青はすべての画面サイズをカバーし、minSDK は 3 です。
- 緑は大画面以上の画面サイズをカバーし、minSDK は 3 です。
- 赤は特大画面（通常はタブレット）をカバーし、minSDK は 9 です。
- 紫はすべての画面サイズをカバーし、minSDK は 11 です。
上記のルールでは、多くの重複があります。たとえば、 API 11 を搭載した特大デバイスでは、指定された 4 つの APK のいずれかを実行できると考えられます。 ただし、「最も高いバージョン番号」を使用する方が有効です。アラートの取り込み順を 次のように設定されます。
紫 ≥ 赤 ≥ 緑 ≥ 青
重複をすべて許容することには理由があります。たとえば、Purple APK には、 他の 2 つはそうではありません[Google Play でのフィルタ] ページ に考えられる原因の完全なリストを記載しています。例として、 Purple には前面カメラが必要であると仮定します。つまり、紫の主要な目的は、前面カメラで撮影を楽しむことです。しかし、API 11 以降のすべてのデバイス 前面カメラも設置できます。その場合はどうなるでしょうか？
幸いなことに、ユーザーがそのようなデバイスから Google Play を閲覧している場合、Google Play は 要件として前面カメラが必須になっていることがわかれば、紫のカメラは静かに無視します。 パープルとそのデバイスはデジタル天国では一致しないと判断しました。次に、Google Play は、赤が特大デバイスに対応しているだけでなく、前面カメラの有無を気にしないことを認識します。ユーザーが Google Play からダウンロードすることは引き続き可能ですが、 というのも、前面カメラに問題が起きたにも関わらず、特定の APK をサポートしていたからです。 API レベル。
すべての APK を別々の「トラック」で管理するには、適切なバージョン コードを用意することが重要です できます。推奨されるコードについては、バージョン コードのエリアをご覧ください。 ご覧くださいセクション全体が参考になりますが、基本的なポイントは、APK のセットを表すコードの構成です。すなわち、2 桁で minSDK を表し、2 桁で最小 / 最大画面サイズを表し、3 桁でビルド番号を表します。こうすれば、デバイスが Android の新しいバージョンにアップグレードされたときに、 対象となり、現在インストールされている APK より優先されるようになった APK が デバイスでは「アップグレード」とみなされます。例に適用した場合のバージョン番号スキーム たとえば、次のようになります。
青: 0304001, 0304002, 0304003...
緑: 0334001, 0334002, 0334003
赤: 0344001, 0344002, 0344003...
紫: 1104001、1104002、1104003...
これらをまとめると、Android マニフェストは次のようになります。 次のとおりです。
青:
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
android:versionCode="0304001" android:versionName="1.0" package="com.example.foo">
<uses-sdk android:minSdkVersion="3" />
<supports-screens android:smallScreens="true"
android:normalScreens="true"
android:largeScreens="true"
android:xlargeScreens="true" />
...
緑:
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
android:versionCode="0334001" android:versionName="1.0" package="com.example.foo">
<uses-sdk android:minSdkVersion="3" />
<supports-screens android:smallScreens="false"
android:normalScreens="false"
android:largeScreens="true"
android:xlargeScreens="true" />
...
赤:
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
android:versionCode="0344001" android:versionName="1.0" package="com.example.foo">
<uses-sdk android:minSdkVersion="3" />
<supports-screens android:smallScreens="false"
android:normalScreens="false"
android:largeScreens="false"
android:xlargeScreens="true" />
...
紫:
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
android:versionCode="1104001" android:versionName="1.0" package="com.example.foo">
<uses-sdk android:minSdkVersion="11" />
<supports-screens android:smallScreens="true"
android:normalScreens="true"
android:largeScreens="true"
android:xlargeScreens="true" />
...
技術的には、複数 APK は supported-screens タグか 宣言します。一般的には supports-screens が好まれます。同じマニフェストで両方のタグを使用することは避けてください。処理が必要以上に複雑になり、誤りが生じる可能性が増えます。 また、デフォルト値（small と normal は常に true です）を活用するのではなく、 マニフェストで各画面サイズの値を明示的に設定します。そうすれば、将来の悩みの種が少なくなります。たとえば、ターゲット SDK が 9 未満のマニフェストでは、「特大」はまだ存在しなかったため、自動的に false に設定されます。画面サイズは必ず明示的に設定しましょう。
リリース前チェックリストを確認する
Google Play にアップロードする前に、次の項目を念入りにチェックしてください。これらは 特に複数の APK に関連するものであり、すべての APK を対象とした完全なチェックリストを表すものではありません。 Google Play にアップロードされる アプリの数を管理できます
- すべての APK のパッケージ名は同じである必要があります。
- APK はすべて、同じ証明書で署名する必要があります。
- プラットフォーム バージョンで APK が重複している場合、minSdkVersion が高いほうの APK に、 使用します。
- APK がサポートするすべての画面サイズをマニフェストで true に設定し、あらゆる画面サイズ false に設定します。
- マニフェスト フィルタで、競合する情報（ XLARGE 画面でカップケーキが表示されると、誰にも表示されません）。
- 各 APK のマニフェストは、サポートされている画面、OpenGL テクスチャ、または プラットフォーム バージョン。
- 1 台以上のデバイスで各 APK をテストします。それ以外では、Google Cloud には カスタマイズ可能なデバイス エミュレータを開発マシン上で実行できます。ぜひ利用してください。
また、市場にリリースする前にコンパイル済みの 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: 'xlarge' supports-any-density: 'true' locales: '--_--' densities: '120' '160' '240'
aapt 出力を調べるときは、Terraform の引数に矛盾する値が supports-screens と compatible-screens、および意図しない「uses-feature」がない値 権限がある結果として追加された権限などです。上記の例では、APK は すべてのデバイスで非表示になります。
その原因は、必要な SEND_SMS 権限の追加により、android.hardware.telephony の機能要件が暗黙的に追加されたことにあります。大部分の xlarge デバイスはテレフォニー ハードウェアを搭載していないタブレットであるため、Google Play はこのような場合にこの APK を除外します。これは、xlarge 画面のサイズをレポートするのに十分な大きさとテレフォニー ハードウェアを搭載したデバイスが今後登場するまでです。
幸いにも、上記の問題は、マニフェストに次の行を追加すれば簡単に解決できます。
<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 が目的のデバイスをターゲットにしていることを確認するため、該当のテストデバイスにアプリをダウンロードします。これで完了です。