各種の画面サイズ用の APK を複数作成する

アプリを Google Play に公開する場合は、Android App Bundle を作成してアップロードしてください。そうすることで、各ユーザーのデバイス構成に合わせて最適化された APK が Google Play によって自動的に生成、配信されるため、ユーザーはアプリの実行に必要なコードとリソースをダウンロードするだけで済みます。複数の APK を公開するという方法は、Google Play に公開しない場合は便利ですが、各 APK のビルド、署名、管理を自分で行う必要があります。

Android アプリを開発して Google Play で複数の APK を利用する場合は、最初からおすすめの方法を採用し、開発プロセスで不必要な問題が生じないようにすることが重要です。このレッスンでは、アプリの APK を複数作成し、それぞれで異なる画面サイズクラスをカバーする方法について説明します。また、複数の APK のコードベースをできるだけ簡単に管理するために必要なツールも利用できます。

複数 APK の必要性を確認する

複数のサイズの Android デバイスで動作するアプリを作成する場合、小画面での互換性やユーザビリティを犠牲にすることなく、アプリがより大きなデバイスの利用可能なスペースをすべて活用したいと考えるのは当然です。最初は複数 APK のサポートが最適なソリューションと思えるかもしれませんが、多くの場合、そうではありません。複数 APK のデベロッパー ガイドの単一 APK の代わりに単一 APK を使用するセクションには、単一の APK でこれを実現する方法(サポート ライブラリの使用など)に関する有用な情報が記載されています。複数画面のサポートに関するガイドもお読みください。Android SDK を使用してダウンロードできるサポート ライブラリもあります。このライブラリを使用すると、Honeycomb より前のデバイスでフラグメントを使用できます(単一の APK での複数画面のサポートがはるかに簡単になります)。

管理できる場合、アプリを単一の APK に制限することで、次のようないくつかの利点があります。

  • 公開とテストがより簡単になります
  • 管理するコードベースは 1 つだけです
  • アプリはデバイス構成の変更に適応できます
  • 複数のデバイスにまたがるアプリの復元が機能します
  • 市場における好み、ある APK から次の APK への「アップグレード」の動作、どの APK がどのクラスのデバイスに対応するかを気にする必要はありません。

このレッスンの残りの部分では、このトピックについて調査し、リンクされたリソースにしっかりと内容を取り込んで、複数の APK がアプリに適していると判断したことを前提としています。

要件を図示する

まず、簡単なグラフを作成して、必要な APK の数と各 APK がカバーする画面サイズをすばやく判断します。幸いなことに、要件を迅速かつ簡単に計画でき、後で参照するために役立ちます。Android プラットフォームで利用可能なさまざまな画面サイズを表すセルの行から始めます。

標準 特大

次に、個々の APK を表す色をセルに塗ります。以下に、各 APK を特定の範囲の画面サイズに適用する方法の一例を示します。

標準 特大

必要に応じて、「小とその他すべて」または「特大とその他」の 2 つの APK を使用することもできます。グラフを色分けすることでチーム内のコミュニケーションも簡単になり、各 APK をカバーする画面の種類の数に関係なく、単に各 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 は「ターゲット」の画面サイズより大きいすべての画面サイズをサポートするように設定されています。個別に考えると、各 APK の可能な範囲は次のようになります。

標準 特大
標準 特大
標準 特大

しかし、「最もバージョン番号が優先」のルールを使用して、各 APK の versionCode 属性を赤 ≥ 緑、青の順に設定すると、グラフは事実上次のように下がります。

標準 特大

さらに、赤の APK には他の 2 つにない要件があると仮定します。考えられる問題の原因の一覧については、Android デベロッパー ガイドの Google Play でのフィルタのページをご覧ください。たとえば、赤色には前面カメラが必要だとします。実際のところ、赤色の APK の目的は、追加の画面スペースを使用して前面カメラで面白いことをすることです。しかし、すべての特大デバイスに前面カメラさえ搭載されていないことがわかりました。その場合はどうなるでしょうか?

幸い、ユーザーがそのようなデバイスから Google Play を閲覧している場合、Google Play はマニフェストを確認し、Red が前面カメラを要件としてリストしていることを確認し、Red とそのデバイスがデジタル天国に一致しないと判断した後は静かに無視します。これにより、緑色が特大デバイスと互換性があるだけでなく、前面カメラの有無も重要ではないことがわかります。ユーザーは、Google Play からアプリをダウンロードできます。これは、前面カメラ全体に問題が発生しましたが、その特定の画面サイズをサポートする APK が残っていたからです。

すべての APK を別々の「トラック」に保存するには、適切なバージョン コード スキームを使用することが重要です。推奨されるバージョンは、デベロッパー ガイドのバージョン コードのセクションに記載されています。APK のサンプルセットでは、想定される 3 つのディメンションのうち 1 つしか扱っていないため、各 APK を 1, 000 単位で区切り、そこから増分すれば十分です。これは次のように表示されます。

青: 1001, 1002, 1003, 1004...
緑: 2001 年、2002 年、2003 年、2004 年...
赤:3001、3002、3003、3004...

まとめると、Android マニフェストは次のようになります。

青:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    android:versionCode="1001" android:versionName="1.0" package="com.example.foo">
    <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="2001" android:versionName="1.0" package="com.example.foo">
    <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="3001" android:versionName="1.0" package="com.example.foo">
    <supports-screens android:smallScreens="false"
        android:normalScreens="false"
        android:largeScreens="false"
        android:xlargeScreens="true" />
    ...

技術的には、複数 APK は supports-screens タグまたは compatible-screens タグのいずれかで動作します。一般的には Supports-screens が推奨されますが、同じマニフェスト内で両方のタグを使用することは一般におすすめできません。処理が不必要に複雑になり、エラーが発生する可能性が高くなります。また、マニフェストではデフォルト値(デフォルトでは小と標準が常に true)を利用するのではなく、各画面サイズの値を明示的に設定しています。そうすれば、将来の悩みの種が少なくなります。たとえば、ターゲット SDK が 9 未満のマニフェストでは、まだサイズが存在しないため、特大サイズが自動的に false に設定されます。あえて明示してください。

リリース前チェックリストを確認する

Google Play にアップロードする前に、次の項目を念入りにチェックしてください。これらは特に複数の APK に関連し、Google Play にアップロードするすべてのアプリの完全なチェックリストを示すものではありません。

  • すべての APK は同じパッケージ名を持つ必要があります
  • すべての APK は同じ証明書で署名する必要があります
  • APK がサポートするすべての画面サイズをマニフェストで true に設定し、回避するすべての画面サイズを false に設定します。
  • マニフェスト フィルタで情報が矛盾していないかを再確認してください(特大画面でのみカップケーキをサポートする APK は誰も見ることができません)。
  • 各 APK のマニフェストは、サポート対象の画面、OpenGL テクスチャ、プラットフォーム バージョンの少なくとも 1 つで一意である必要があります
  • 1 台以上のデバイスで各 APK をテストします。それ以外では、ビジネスで最もカスタマイズ性の高いデバイス エミュレータの一つを開発マシンに置いておく必要があります。ぜひ利用してください。

また、市場に投入する前にコンパイル済み 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 の出力を調べるときは、supports-screens と compatible-screens の値が競合していないこと、マニフェストで設定した権限の結果として追加された意図しない「uses-feature」値がないことを確認してください。上記の例では、(すべてのデバイスではないにしても)ほとんどのデバイスで APK が見えません。

その原因は、必要な SEND_SMS 権限の追加により、android.hardware.telephony の機能要件が暗黙的に追加されたことにあります。ほとんどの特大画面デバイス(すべてではないにしても)はテレフォニー ハードウェアを搭載していないタブレットであるため、このような場合、Google Play は、特大画面サイズとして報告できる大きさとテレフォニー ハードウェアの両方を備えたデバイスが今後登場するまで、このような 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" />

リリース前チェックリストが完了したら、APK を Google Play にアップロードします。 Google Play でブラウジングしたときにアプリが表示されるまでに少し時間がかかることがありますが、表示されたら最後のチェックを行います。任意のテストデバイスにアプリをダウンロードします。APK が目的のデバイスをターゲットにしていることを確認する必要があります。

Google Play で複数の APK を公開する方法について詳しくは、複数 APK のサポートをご覧ください。