アプリを Google Play に公開する場合は、Android App Bundle を作成してアップロードしてください。そうすることで、各ユーザーのデバイス構成に合わせて最適化された APK が Google Play によって自動的に生成、配信されるため、ユーザーはアプリの実行に必要なコードとリソースをダウンロードするだけで済みます。複数の APK を公開するという方法は、Google Play に公開しない場合は便利ですが、各 APK のビルド、署名、管理を自分で行う必要があります。
Android アプリを開発して Google Play の複数の APK を利用する場合は、 最初から適切な方法を採用して 不必要な頭痛の種を防ぐことが重要 開発プロセスに進みますこのレッスンでは、Android または iOS モバイル デバイスに それぞれわずかに異なる API レベルをカバーしています。また、Google Cloud の 複数 APK のコードベースをできるだけ簡単に維持できるようにする必要があります。
複数 APK の必要性を確認する
複数の世代の Android で動作するアプリを作成する場合 当然ながら、新しいデバイスで新機能を利用する場合は、 互換性を犠牲にすることなく開発できます最初は複数 APK のように思えるかもしれませんが、 サポートが最適なソリューションといえますが、多くの場合はそうではありません。単一 APK の使用 複数 APK のデベロッパー ガイドのセクションに、 サポート ライブラリの使用を含め、単一の APK でこれを実現できます。また、 特定の API レベルでのみ実行されるコードを単一の APK で記述でき、 からのリフレクションなど、コンピューティング負荷の高い手法が こちらの記事をご覧ください。
管理できる場合、アプリを 1 つの APK に制限すると、 次のような利点があります。
- 公開とテストがより簡単になります
- 管理するコードベースは 1 つだけです
- アプリはデバイス構成の変更に適応できます
- 複数のデバイスにまたがるアプリの復元が機能します
- 市場選好や「アップグレード」による行動を心配する必要がないを 1 つの APK から どの APK をどのクラスのデバイスに適用するか
このレッスンの残りの部分は、トピックについて調査し、 リンク先のリソースのマテリアルにあり、複数の APK がアプリのパスとして適切であると判断されました。 説明します。
要件を図示する
まず、必要な APK の数と API を素早く確認できる簡単なグラフを作成します。 制限します。詳しくは、プラットフォームのバージョンに関するページを Android デベロッパー ウェブサイトでは、特定のデバイスを実行しているアクティブなデバイスの相対数に関するデータを提供しています ダウンロードする必要がありますまた、初めは簡単そうに見えますが、どの集合を 各 APK の対象 API レベルの上限がかなり高くなってしまうため、 重なることもあります（多くの場合は重複します）。幸い、要件をチャート化するのは簡単で、 後で簡単に参照できます。
複数 APK のグラフを作成するには、 API レベルをサポートしています。未来を表すために末尾に追加のセルをスローします できます。
| 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | + |
次に、個々の APK を表す色をセルに塗ります。これは、Google Chat で 各 APK を特定の範囲の API レベルに適用できます。
| 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | + |
この図が完成したら、チームに配布します。プロジェクトに関するチームコミュニケーション 「API レベル 3 ～ 6 の APK はどうですか？」と尋ねる代わりに、 Android 1.x です。うまくいってる？」と尋ねる代わりに、「青の 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-red
プロジェクトを作成したら、ライブラリ プロジェクトを各 APK プロジェクトへの参照として追加します。条件 ライブラリ プロジェクトで開始アクティビティを定義し、APK でそのアクティビティを拡張する できます。ライブラリ プロジェクト内で開始アクティビティを定義すると、 アプリの初期化を 1 か所で行えるため、APK ごとに初期化を 「ユニバーサル」なライセンス チェックの実行など、さまざまなタスクに APK から APK に大きく変更されない初期化手順。
マニフェストを調整する
ユーザーが複数の APK を使用するアプリを Google Play からダウンロードした場合、 使用する APK は、次の 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 つにはない要件があるとしましょう。 /Google Play のフィルタページ Android デベロッパー ガイドに、考えられる原因の一覧が記載されています。対象: 例として、赤色には前面カメラが必要であるとします。実際のところ、 赤の APK は、前面カメラと API に追加された便利な新機能を組み合わせたものです。 11.しかし、実のところ、API 11 をサポートするすべてのデバイスに前面カメラが搭載されているわけではありません。「 ホラー！
幸いなことに、ユーザーがそのようなデバイスから Google Play を閲覧している場合、Google Play は Red が前面カメラを要件としてリストしていることを確認して、静かに無視し、 Red とそのデバイスはデジタル天国では一致しないと判断しました。その後、 緑色は、API 11 を搭載したデバイスと上位互換性があるだけでなく（maxSdkVersion が定義されていないため）、 前面カメラの有無も関係ありません。アプリはダウンロード可能です ユーザーが Google Play から写真を送信することで、 その特定の API レベルをサポートする APK。
すべての APK を別々の「トラック」で管理するには、適切なバージョン コードを用意することが重要です できます。推奨されるコードについては、次の記事のバージョン コードをご覧ください: ご覧くださいこの例の APK セットは 3 つの可能なうちの 1 つしか扱っていないため、 各 APK を 1,000 ずつ区切り、最初の数桁を 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 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: 'small' 'normal' 'large' 'xlarge' supports-any-density: 'true' locales: '--_--' densities: '120' '160' '240'
aapt 出力を調べるときは、Terraform の引数に矛盾する値が 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 が目的のデバイスをターゲットにしていることを確認するため、該当のテストデバイスにアプリをダウンロードします。これで完了です。