アプリを Google Play に公開する場合は、Android App Bundle を作成してアップロードしてください。そうすることで、各ユーザーのデバイス構成に合わせて最適化された APK が Google Play によって自動的に生成、配信されるため、ユーザーはアプリの実行に必要なコードとリソースをダウンロードするだけで済みます。複数の APK を公開するという方法は、Google Play に公開しない場合は便利ですが、各 APK のビルド、署名、管理を自分で行う必要があります。
Android アプリを開発して Google Play の複数の APK を利用する場合は、 最初から適切な方法を採用して 不必要な頭痛の種を防ぐことが重要 開発プロセスに進みますこのレッスンでは、Android または iOS モバイル デバイスに それぞれ異なる画面サイズに対応していますまた、次のことを行うために必要なツールも 複数 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 つに分ける場合の例です。青は小画面または標準画面のデバイス、緑は大画面デバイス 3 から 10 の範囲の API 範囲があります。紫色は 特殊なケースです。ただし、すべての画面サイズに適用されますが、API 11 以降のみが対象となります。さらに重要なのは、 この表を見ると、特定の API と画面サイズの組み合わせに対応する APK がすぐにわかります。宛先 それぞれにおしゃれなコードネームもあります。「上で赤をテストしたのか」多い 「Xoom に対して 3 ～ 10 の特大 APK をテストしたことはありますか？」と聞くよりも、キュービーに尋ねる方が簡単です。これを印刷 コードベースの作業を行うすべての人に提供します。そうすれば、仕事がずっと楽になります。
ライブラリ プロジェクトにすべての共通のコードとリソースを配置する
既存の Android アプリを変更する場合でも、ゼロから作成する場合でも、 コードベースに対してまず行うべきであり 圧倒的に最も重要なことですすべて 更新が必要なのは 1 回だけです（言語にローカライズされた文字列、 カラーテーマ、共有コードのバグ修正）によって開発時間を短縮し、 間違いの可能性が高まります。
注: 作成方法と作成方法の実装の詳細は、 このレッスンでは説明しませんが、インクルード ライブラリの Android ライブラリを作成するをご覧ください。
既存のアプリを変換して複数 APK サポートを使用するには、 ローカライズされたすべての文字列ファイル、値のリスト、テーマについてコードベースを精査する 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 に大きく変更されない初期化手順。
マニフェストを調整する
ユーザーが複数の APK を使用するアプリを Google Play からダウンロードした場合、 使用する APK は、次の 2 つのシンプルなルールに従って選択します。
- マニフェストで特定の 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 には前面カメラが必要であると仮定します。Purple のポイントは、 前面カメラでエンターテイメントを楽しめます。しかし、API 11 以降のすべてのデバイス 前面カメラも設置できます。その場合はどうなるでしょうか？
幸いなことに、ユーザーがそのようなデバイスから Google Play を閲覧している場合、Google Play は 要件として前面カメラが必須になっていることがわかれば、紫のカメラは静かに無視します。 パープルとそのデバイスはデジタル天国では一致しないと判断しました。その後、 Red は xlarge デバイスと互換性があるだけでなく、 前面カメラがある！ユーザーが Google Play からダウンロードすることは引き続き可能ですが、 というのも、前面カメラに問題が起きたにも関わらず、特定の APK をサポートしていたからです。 API レベル。
すべての APK を別々の「トラック」で管理するには、適切なバージョン コードを用意することが重要です できます。推奨されるコードについては、次の記事のバージョン コードをご覧ください: ご覧くださいセクション全体を読む価値がありますが、基本的な要点はこの一連の APK では、minSDK を表す 2 桁、最小/最大画面サイズを表す 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 は xlarge そのサイズが存在しないため、自動的に false に設定されます。はっきりと表現しましょう。
リリース前チェックリストを確認する
Google Play にアップロードする前に、次の項目を念入りにチェックしてください。これらは 特に複数の APK に関連するものであり、すべての APK を対象とした完全なチェックリストを表すものではありません。 ダウンロードされる場合もあります。
- すべての 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 Asset Packaging ツールの作成と 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 が目的のデバイスをターゲットにしていることを確認するため、該当のテストデバイスにアプリをダウンロードします。これで完了です。