Docs‎ > ‎

Multiple APK Support - 日本語訳

Quickview

  • 異なるコンフィギュレーションのデバイスに対して異なる APK を同時に公開
  • APKは、マニフェストの内容に基づいてフィルタリングされた上で配布される
  • 複数 APK は、単一の APK では全てのデバイスをサポートできない場合や合理的な理由がある場合のみ使用するべき

In this document

  1. Publishing Concepts
    1. Active APKs
    2. Simple mode and advanced mode
  2. How Multiple APKs Work
    1. Supported filters
    2. Rules for multiple APKs
  3. Creating Multiple APKs
    1. Assigning version codes
  4. Using a Single APK Instead
    1. Supporting multiple GL textures
    2. Supporting multiple screens
    3. Supporting multiple API levels

See also

  1. Market Filters
  2. Supporting Multiple Screens
  3. Compatibility Package
  4. Android API Levels

マルチプル(複数) APK サポートは、デバイスコンフィギュレーションの違う端末に対して別々の APK を公開することを可能にするアンドロイドマーケットの機能です。それぞれの APK は完全で独立したアプリケーションですが、アンドロイドマーケット上で1つのアプリケーションとして表示されるためにはパッケージ名や署名に使用する証明書は同じでなければなりません。この機能は、単一の APK では対象デバイスの全てをカバーできない場合に便利です。

アンドロイドデバイスは様々な点で差異がありますが、アプリケーションを成功させるためには出来る限り多くのデバイスで利用可能にすることが重要です。アンドロイドアプリケーションは通常、コンフィギュレーションに応じて用意したリソース(例えばスクリーンサイズに応じた様々なレイアウト等)からアンドロイドシステムが適切なものを実行時に選択してくれる仕組みを利用することで単一の APK でも様々なでデバイス上で正しく動作させることが可能です。しかし、代替のリソースを含めることにより APK が大きくなりすぎてしまう(50MB を超える)場合やその他の技術的な理由により単一の APK では全てのコンフィギュレーションをサポートすることができないケースも存在します。

出来る限りたくさんのデバイスを単一の APK でサポートするようにアプリケーションを開発することを推奨しますが、時にはそれが不可能な場合もあります。アプリケーションを出来る限り多くのデバイスに対して提供できるようにするため、アンドロイドマーケットは1つのアプリケーションとして複数の APK を公開することを可能にしています。アンドロイドマーケットはそれぞれのデバイスに対して、マニフェストファイルのコンフィギュレーションサポート情報を基に適切な APK を選択して提供します。

アプリケーションを複数 APK で公開することにより、それぞれの APK で以下のことが可能になります。

  • 異なる OpenGL テクスチャ圧縮フォーマットのサポート
  • 異なるスクリーンコンフィギュレーションのサポート
  • 異なるプラットフォームバージョンのサポート

現在、アンドロイドマーケットは上記の点の違いのみを APK 選択の際の基準として用いることができます。

注: 一般的には、単一のAPK で異なるデバイスコンフィギュレーションをサポートすると APK のサイズが大きくなりすぎてしまう(50MB を超える)場合のみマルチプル APK を使用すべきです。単一の APK により様々なコンフィギュレーションをサポートすることが常にベストプラクティスです。というのも、ユーザーに取ってアプリケーションアップデートパスがシンプルでクリアなものになり、あなたにとっても開発と公開作業の複雑さから解放され人生がよりシンプルになるからです。マルチプル APK を公開する前に、この後にある「Using a Single APK Instead」という節を読んでどの選択肢をとるかを検討してください。

Publishing Concepts

アンドロイドマーケットでマルチプル APK を公開し始める前に、アンドロイドマーケットパブリッシャーサイトの仕組みに関するいくつかの概念を理解する必要があります。

Active APKs

"Publish(公開)"と"Save(保存)"の違いについて

アプリケーションの編集画面の右上には、2つのボタンがあります。1つはPublishもしくはUnpublish(非公開)、そしてもう1つはSaveです。(Saveボタンの振る舞いは場合によって変わります)

あなたのアプリケーションをマーケットに新規登録するか、もしくは未だ非公開である場合、1つ目のボタンの表示はPublishになっています。そのボタンをクリックするとどんなAPKであってもActiveとしてリストに追加され、Android Market上で入手可能となります。同様に、新規登録時もしくは非公開の場合、Saveをクリックすると、すべての変更、つまりProduct details(商品の詳細)に追加した情報や、アップロードしたAPKなどが保存されます。しかしこのとき、Android Marketから見えるようにはなりません。この機能は、アプリの公開を決定する前でも、各種の変更を保存してパブリッシャーサイトをサインアウトできるようにするためのものです。

アプリケーションを公開後、1つ目のボタンはUnpublishに変わります。これをクリックすることで、アプリケーションを非公開にし、全てのAPKをAndroid Market上で入手できないようにします。また、公開中のアプリケーションでは、Saveボタンの振る舞いが変わります。Saveをクリックすると変更点を保存するだけではなく、そのまま変更点をAndroid Marketへと公開するのです。例えば、あなたがアプリケーションを公開した状態でproduct detailsに変更を加えたり、新たにAPKをActiveにしたとき、Saveボタンはそれらの変更を全てAndroid Marketで有効にします。

単一APKであるか複数APKであるかにかかわらず、アプリケーションを公開する前に APK filesタブから APK を アクティブ(active) にする必要があります。アクティブにされた APK は、アクティブ APK リストへ移動されます。このリストで公開しようとしている APK を確認します。

もしエラーがなければ、アプリケーションが非公開の場合は公開(Publish)ボタンをクリックすることで、アプリケーションが既に公開されている場合は保存(Save)ボタンをクリックすることで全てのアクティブな APK はマーケットに公開されます。

Simple mode and advanced mode

アンドロイドマーケットパブリッシャーサイトはアプリケーションに関連付けられた APK 群を管理するための2つのモード(シンプルモードとアドバンストモード)を提供します。APK files タブの右上にあるリンクをクリックすることでモードを切り替えることができます。

シンプルモードはアプリケーションを公開するための既存の方法で、単一の APK のみを使用します。シンプルモードでは、同時に1つの APK のみをアクティブにすることができます。アプリケーションの更新のために新たな APK をアップロードして"Activate"をクリックすると、それまでアクティブだった APK はデアクティベートされます(新しい APK を公開するためには、Save をクリックする必要があります)。

アドバンストモードは特定のデバイスコンフィギュレーション向けに作成された複数の APK のアクティベートと公開を可能にするモードです。しかし、同時にアクティブに出来る APK のマニフェストの内容についてはいくつかのルールが存在します。アクティブにした APK がルールのいずれかに違反するばあい、エラーや警告メッセージが表示されます。エラーの場合はエラーを解消するまで公開することはできません。警告であればアクティブにされた APK を公開することはできますが、想定とは異なるデバイスでアプリケーションが使用されるなどの意図しない結果を招く場合があります。ルールの内容については後述します。

マルチプル(複数の)APKの仕組み (How Multiple APKs Work)

Android Market上でマルチプル(複数の)APKを扱う上でのコンセプトは、デバイスによってダウンロードされるAPKが異なるかもしれませんが、Android Market上にあるあなたのアプリのエントリーはひとつしかないということです。これはどういうことかと言うと:

  • アプリの情報(アプリの説明、アイコン、スクリーンショットなど)はひとつだけメンテすればおっけーです。でもこのことは、APKが異なっても値段設定を個別にできないということでもあります。
  • 全てのユーザーは、Android Market上にあるあなたのアプリがひとつのバージョンのものしか見えないので、"タブレット用"や"スマフォ用"のように違ったバージョンのアプリに惑わされることがありません。
  • 異なるデバイスのユーザーは異なったAPKを使っているかもしれませんが、ユーザーレビューとしてはひとつのアプリとしてまとまって表示されます。
  • 異なったAndroidのバージョン用(異なったAPIレベル用)に分けたAPKを公開した場合、ユーザーのデバイスは、あなたが公開しているAPKのいずれかのシステムアップデート通知を受け取ります。そして、Android Marketはユーザーのアプリをより高いAndroidのバージョンをサポートしているアプリにアップデートします。そのアプリに関係するシステムデータは保持されます。(ひとつのAPKしか使ってないときと同じように通常のアプリのアップデートとして)

ひとつのアプリとして複数のAPKを公開するには、前のセクションで書いているように、アプリケーションのAPK filesタブからアドバンスドモードを有効にしなければなりません。アドバンスドモードを有効にすると、ひとつのアプリとして複数のAPKのアップロード、アクティベート、公開ができるようになります。以降のセクションでは、これらの仕組みについてより詳しく説明します。

サポートされているフィルタ (Supported filters)

どのデバイスがどのAPKをインストールできるかは、APKのマニフェストファイルに定義されている要素である Android Market filters によって決まります。Android Marketは、各々のAPKがこれらのフィルタを使ってデバイスの特徴のバリエーション(以降に示します)をサポートするときに限ってマルチプルAPKの公開を許します。:

  • OpenGL テクスチャ圧縮フォーマット

    マニフェストファイルの <supports-gl-texture> 要素に基づきます。

    例えば、OpenGL ESを使ったゲームを開発しているときに、ATIテクスチャ圧縮をサポートしたAPKと、PowerVR圧縮(や他の多くのものなども含めた)をサポートしたAPKを分けて公開することができます。


  • スクリーンサイズ(と、スクリーン密度)

    マニフェストファイルの <supports-screens> 要素や <compatible-screens> 要素に基づきます。極力、これらふたつの要素の両方を使わずに、 <supports-screens> 要素のみを使うべきです。

    例えば、smallとnormalのスクリーンサイズをサポートしているAPKと、largeとxlargeのスクリーンサイズをサポートしている別のAPKを公開することができます。

    Note: Androidシステムは、アプリケーションがひとつのAPKで全てのスクリーンコンフィグレーションをサポートできるよう強力な機能を提供しています。本当に必要でないかぎり、異なったスクリーンに対応する目的で複数のAPKに分けるようなことは避け、 Supporting Multiple Screens のガイドラインを読むべきです。そうすることで、あなたのアプリは柔軟性に富み、ひとつのAPKで全てのスクリーンコンフィグレーションをサポートできるようになります。

    Caution: デフォルトでは、 <supports-screens> 要素に含まれる全てのスクリーンサイズの属性は、特に宣言しないかぎり"true"になっています。しかしながら android:xlargeScreens 属性は、Android 2.3 (API レベル 9)から追加されたため、Android Marketは、あなたのアプリの android:minSdkVersion か android:targetSdkVersion のどちらかが9以上でなければ、この属性を"false"とみなすでしょう。

    Caution: マニフェストファイルに <supports-screens> 要素と <compatible-screens> 要素の両方を組み合わせないようにすべきです。両方使っていると、これらがコンフリクトしてエラーになることが多くなります。 Distributing to Specific Screens は、どのように使うかを判断する指針になります。両方使うことを避けられないなら、与えられたサイズの中で一致しているコンフリクトに関しては"false"が勝つので気をつけておいて下さい。


  • API レベル

    マニフェストファイルの  <uses-sdk> 要素に基づきます。 android:minSdkVersion 属性と android:maxSdkVersion 属性の両方を使って異なるAPIレベルをサポートしていることを明らかにすることができます。

    例えば、API レベル 4 - 7 (Android 1.6 - 2.1)をサポートするAPK(APIレベル4以下のAPIのみ使えます)と、APIレベル8(Android 2.2)以上をサポートする別のAPK(APIレベル8以下のAPIが使えます)のふたつを含んだアプリを公開できます。

    Note:

    • この特徴を複数のAPKを識別するために使った場合、 android:minSdkVersion の値が高いものほど、 android:versionCode の値を高くしなければなりません。これは、二つのAPKがサポートしているデバイスに重複があるときにも言えることです。このことで、デバイスがシステムアップデートを受け取ったときにAndroid Marketはアプリのアップデートをユーザーに促すことができます。(なぜなら、アップデートはアプリのバージョンコードの値が増加したときに発生するからです。)この要件については、以降の Rules for multiple APKs で説明されています。
    • 原則として、 android:maxSdkVersion は使わないようにすべきです。なぜなら、パブリックなAPIを使ってアプリを正しく開発しているかぎり、将来のAndroidのバージョンと常に互換性があるからです。異なったAPKをより高いAPIレベル用に公開したいと思ったとしても、バージョンの上限を指定する必要はなく、 android:minSdkVersion が "4" のものと "8" のもののふたつのAPKを用意することで、APIレベル8以上をサポートしているデバイスでは、常に 後者("8")のAPKが使えるようになります。(なぜなら、一つ前のNOTEで示したように、こちらのAPKのバージョンコードの方が高い値が振られているからです。)

マニフェストファイルに含まれる Android Market filters を有効にする他の(上で示していない)要素ものは、従来通り働きますが、Android Marketはこれらのバリエーションの違いのみによって複数のAPKを公開することは許していません。つまり、(マニフェストファイルで他の要素に違いがあったとしても)上で示したフィルタが全く同じAPKをマルチプルAPKとして公開することはできません。例としては、ふたつのAPKに、 <uses-configuration> しか違いが無いような場合などです。

マルチプル(複数の)APKのルール(Rules for multiple APKs)

あなたがアドバンスドモードを有効にしてアプリをマルチプルAPKとして公開する前に、以下のようなルールを理解しておく必要があります。これらのルールはマルチプルAPKを公開する仕組みがどのようになっているかを示しています。:

  • 同じアプリとして公開する全てのAPKは、同じパッケージ名をつけ、同じ認証キーで署名されていなければなりません
  • APKは各々異なったバージョンコードをつけなければなりません。バージョンコードは android:versionCode 属性で指定します。
  • 各々のAPKでサポートするコンフィグの内容を他のAPKと完全に一致させてはいけません

    少なくとも、上のセクションで示したマーケットフィルタ( supported Market filters )のどれかひとつくらいは変えておいて下さい。

    大抵の場合、ある特定の特徴(サポートされているテクスチャ圧縮フォーマットなど)によってAPKを分けることになるでしょう。こんな風に各々のAPKは異なるデバイスをサポートします。でも複数のAPKがサポートするデバイスに重複があってもおっけーです。サポートするデバイスのコンフィグのいくつかが重複していて、そのデバイスをサポートするAPKが2つあった場合、( android:versionCode で指定される)バージョンコードがより高いものがダウンロードされるでしょう。

  • APKを新しく差し替えるとき、今のものより低いバージョンコードを付けることはできません。例えば、バージョンコードが0400のアクティブなAPKがあったとします。このAPKはスクリーンサイズがsmallからnormalまでを対象にしていたとします。で、同じスクリーンサイズを対象とする、バージョンコードが0300のAPKに差し替えようと試みたとします。これはエラーになります。なぜなら、今までのAPKを使っているユーザーがアプリをアップデートできなくなるからです。
  • 高いAPIレベルを要求するAPKほど、高いバージョンコードを付けておいて下さい

    例えば、複数のAPKのマーケットフィルタ( supported market filters )に、要求するAPIレベル以外の違いが無かったり、他に違いがあったとしても、複数のAPKがフィルタに引っかかったりすることがある場合には気をつけなければなりません。何故このことが重要なのかというと、Android Marketからのアプリのアップデートをデバイスが受け取るタイミングは、Android Market上のアプリのバージョンコードが、デバイスにインストールされているアプリのバージョンコードより高い場合だからです。このことで、デバイスは、より高いAPIレベルをサポートしているAPKを優先してアップデートできるようになります。なぜなら、そのAPKの方がバージョンコードが高いからです。

    Note: バージョンコードを毎回どれくらい増やすか(増分)は関係ないです。ただ単に、より高いAPKレベルのものに、より高いバージョンコードをつけておく必要があるってだけの話です。

    例としては:

    • APIレベル4用(つまりAndroid 1.6以上)に、バージョンコード0400のAPKをアップロードしていたとしたら、APIレベル8用(Android 2.2以上)のAPKは、バージョンコードは、0401以上にしなければなりません。この場合、マーケットフィルタにAPIレベルしか違いが無いので、ユーザーがちゃんとアップデートできるように各々のAPKのバージョンコードを相関させながら上げていく必要があります。
    • APIレベル4用(Android 1.6以上)のsmallからlargeまでのスクリーンをサポートするAPKと、APIレベル8用(Android 2.2以上)のlargeからxlargeまでをサポートするAPKがあった場合も上と同様です。この場合、APIレベル以外にスクリーンサイズもマーケットフィルタに使われますが、スクリーンサイズがlargeの場合などに対象となるAPKが重複するからです。なので、バージョンコードは依然として順番に付けなければなりません。こうしておくと、largeスクリーンのデバイスは、APIレベル8の方のAPKでアップデートされるようになります
    • APIレベル4用(Android 1.6以上)のsmallからnormalまでのスクリーンをサポートするAPKと、APIレベル8用(Android 2.2以上)のlargeからxlargeまでをサポートするAPKの場合は、あまりAPIレベルの相関は気にしなくていいです。なぜならスクリーンサイズのフィルタのおかげで、どんなデバイスであっても二つのAPK両方が対象となることがないからです。だからこの場合は、高いAPIレベルほど高いバージョンコードを付ける必要はありません。

あなたが複数のAPKを使おうとしたときに、Android Marketのパブリッシャーサイトで上で書いたようなルールを守れずにエラーになったとしたら、そのエラーを解消するまで、あなたのそのアプリケーションを公開できないでしょう。

複数のAPKをアクティベート(Marketにアップロード)するとき、何らかの別のコンフリクトが原因で、エラーと言うか、警告が出ることがあります。 警告が出る理由としては以下のようなケースがあります。:

  • APKがサポートするデバイスの特徴の範囲を”狭め”て、そのことが原因でサポート外になったデバイスを、他のどのAPKもサポートしていないケースです。どういうことかと言うと、例えば、今のAPKが smallとnormalのスクリーンサイズをサポートしていたとして、そのAPKがサポートするスクリーンサイズをsmallだけに変えたとします。こうすると、サポートするデバイスの候補を"狭め"たことになり、いくつかのデバイスではもうそのアプリケーションをAndroid Marketで見ることができなくなります。normalのスクリーンサイズをサポートした別のAPKをもうひとつ加えることで、今までサポートしていたデバイスをサポートし続けることができます。
  • 二つ以上のAPKで”重複”があるケースです。 例えば、あるAPKがsmallとnormalとlargeのスクリーンサイズをサポートし、一方、もうひとつのAPKがlargeとxlargeのスクリーンサイズをサポートしていたとしたら、両方のAPK共にlargeスクリーンをサポートしているので、重複があることになります。これをそのままにしていたとしたら、両方のAPKのいずれの対象にもなるデバイス(上の例で言うとlargeスクリーンのデバイス)は、常にバージョンコードが最も高いAPKを受け取ります。

このようなコンフリクトが起きたときは警告のメッセージが出ますが、アプリケーションを公開することはできます。

Creating Multiple APKs

あなたがマルチプル(複数の)APKを公開すると決めれば、公開するAPKごとの個別のAndroidプロジェクトを作成する必要があるでしょう。これは、単純に既存のプロジェクトを複製して、新しい名前を付ければ良いのです。
(あるいは、あなたは、例えばテクスチャ画像のような、異なるリソースを出力するのにビルドシステムを使うことができるかもしれません)

Tip: 巨大なアプリケーションのコードの複製を防止する一つの方法として、ライブラリプロジェクトを使う方法があります。 ライブラリプロジェクトは、それぞれのアプリケーションごとに、共有するコード及びリソースを保持します。

1つのアプリケーションのためにマルチプル(複数の)プロジェクトを作成する際、それぞれが対応するデバイスの制約を簡単に示すための最善の方法が有ります。たとえば、APIレベル8以上に対応するアプリケーションは、HelloWorld_8と言う名前にすると良いのです。

注意: あなたが同じアプリケーションとして発行する全てのAPKは、同じパッケージ名を持ち、同じ証明書によって署名されている必要があります。 マルチプル(複数の)APKの個別のルールについては、Rules for multiple APKs.を参照してください。

バージョンコードの割り当て(Assigning version codes)

1つのアプリケーションの各々のAPKは、android:versionCode属性で、重複のないバージョンコードを割り当てなくてはなりません。
そして、あなたは、マルチプル(複数の)APKを公開する際、バージョンコードの割り当てには注意しなければなりません。なぜならば、それらは個別には異なるものですが、いくつかのケースにおいては、それぞれのAPKのサポートする範囲に基づいて、順序を定義しなくてはならず、また、順序を定義しておくべきだからです。

バージョンコードの順序(Ordering version codes)

高いAPIレベルに対応したAPKは、より大きなバージョンコードである必要があります。たとえば、あなたが異なるAPIレベルをサポートする2つのAPKを作成するとします。この場合、より高いAPIレベルをサポートするAPKのバージョンコードは、低いAPIレベルのバージョンコードより、大きくなければなりません。
これは、デバイスがシステムアップデートを受けて、より高いAPIレベルに適したAPKをインストールする際に、ユーザーがアプリケーションのアップデート通知を確実に受け取るためです。

この必要条件に関するさらに詳しい解説は、Rules for multiple APKsのセクションを参照してください。

あなたは更に、サポートの範囲が重複する複数のAPKがユーザーに及ぼす影響、また、将来の更新時にあなたが作成するであろうAPKが、どのような順序になるのか。バージョンコードの順序を考えるべきです。

一つ例を挙げましょう。スクリーンサイズに基づいた、例えば、一方が「small - normal」、他方が「large - xlarge」に対応したAPKがあるとします。しかし、あなたが将来、一方を「small」、他方を「normal - xlarge」に変更することを予期した際、あなたは「large - xlarge」の方のバージョンコードを大きくするべきです。
そうすれば、スクリーンサイズnormalのデバイスは、あなたが変更した際に、最適な更新を受け取ることが出来るでしょう。なぜならば、新しくデバイスをサポートしたAPKのバージョンコードが、既存のAPKのバージョンコードより増加しているからです。

更に、OpenGLテクスチャの圧縮フォーマットのサポートの違いに基づくマルチプル(複数の)APKを作成する際、多くのデバイスは複数の圧縮フォーマットをサポートしている事に注意してください。

デバイスは、対応が重複する二つのAPKが有ったとき、より高いバージョンコードを持つAPKを受け取ります。

あなたは、APKの中で、より適した圧縮フォーマットに対応したAPKに、より高いバージョンコードを割り当てて、順番を設定するべきです。例えばあなたが、PVRTC、ATITC及びETC1のそれぞれの圧縮フォーマットに対応するAPKを、個々にビルドしたいとします。
この場合、もしあなたがこれらのフォーマットの順序を正確に選ぶなら、PVRTCに対応するAPKのバージョンコードが一番大きく、そして、ATITCはそれより小さく、そして、ETC1は一番小さいバージョンコードであるべきです。
このようにすることで、デバイスがPVRTCとETC1の両方をサポートしていたならば、PVRTC対応のAPKを受け取ります。なぜならば、PVRTC対応のAPKが、より大きなバージョンコードを持っているからです。

バージョンコード体系の使用(Using a version code scheme)

例えば、1つのAPKのみバグフィックスする場合などは全てのAPKをアップデートする必要はありません。この場合のように各APKが他のAPKに依存しないよう更新できるようにするためには、バージョンコード体系を使うべきです。この体系は各APKのバージョンコードを上げる際、他のAPKのバージョンコードを上げる必要がないように、十分な空きを確保したものであるべきです。そして、実施のバージョン名をコードの中に含めるべきです(バージョン名とはandroid:versionNameで指定できるユーザの目に触れるバージョンのことです)。

注意:APKのバージョンコードを上げると、Android Marketは旧バージョンのユーザにアプリケーションのアップデートを促します。したがって、不要なアップデート作業を避けるために、実際に変更が入ってないAPKのバージョンは上げるべきではありません。

バージョンコードは少なくとも7ケタ以上で使うことをお勧めします。上位桁にサポートしている構成を表し、下位桁に(android:versionNameで指定される)バージョン名を示す整数で構成します。例えば、アプリのバージョン名が3.1.0で、APKにAPIレベル4向けとAPIレベル11向けのものがある場合、バージョンコードは0400310と1100310というような感じになります。最初の2桁はAPIレベルのために予約されます(ここでは4と11です)。そして次の2桁は画面サイズやGLテクスチャ形式のどちらかに使用されます(今回の例では使用されていません)。そして下3桁はアプリケーションのバージョン名(ここでは3.1.0)のために予約します。図1で、プラットフォームバージョン(APIレベル)と画面サイズに基づいて2つに分けた場合の例を示します。


図1.推奨するバージョンコード体系(最初の2桁はAPIレベルを、次の2桁は画面サイズの最小と最大(1〜4で4種類のサイズを表している)またはテクスチャ形式を、最後の3桁はアプリのバージョンに使用している)

このバージョンコード体系は、あなたのアプリが発展したとき拡張できるパターンを確立するための、ただの推奨例です。特にこの体系は異なるテクスチャ圧縮形式に対しては考慮していません。この場合、1つのオプションとして、アプリケーションがサポートする圧縮形式ごとに異なる整数を割り当てたテーブル(例えば1がETC1に、2がATITCに対応するなど)を定義したりするといいかもしれません。

おもうままにどんな体系も使用できますが、自分のアプリケーションの将来のバージョンをどのようにバージョンコードで上げる必要があるか、そして例えばシステムアップデートによるデバイス構成が変化する時デバイスがどのようにアップデートされるか、1つまたは複数のAPKの構成サポートをいつ変更するかを慎重に考えるべきです。

Using a Single APK Instead(Multiple APKを使わずに従来通りのSingle APKで対応するやりかたに関して)

Multiple APKを用いてアプリケーションをAndroid Marketで公開するためには通常のやりかた(単一のAPKをAndroid Marketに公開)と比べて考慮しなければいけない点が多くあります。そのため、ほとんどのケースにおいてはMultiple APKを使わずにSingle APKで対応することを強く推奨します。あなたがSIngle APKでの対応がこれ以上困難だと判断した場合にのみMultiple APKでの対応を考えるべきです。

Single APKでの対応はMultiple APKと比べて以下のような利点があります。

  • Android Marketへのアプリケーションの公開および公開後のメンテナンスの容易性

    Multiple APKの場合、それぞれのAPKがどの用途で分けられているかを常に意識する必要があるため、メンテナンス時や問題が発生した場合に混乱する可能性があります(どのAPKに問題があるのかを混同しやすい)。Single APKであればこのようなことは起きません。また、バージョンアップ時にもversion codeは単純にインクリメントしていくだけで済みます。

  • ソースコードのメンテナンスの容易性

    Multiple APKの場合、 library project を活用して複数のプロジェクト間でソースコードを共用するようにしたとしても、いくつかのコードは共通で使うにも関わらずプロジェクト間でコピー&ペーストをしないといけない箇所が残ると思います。これはソースコードのメンテナンスを困難にします(特にバグ修正の場合には)。

  • configuration changeへの対応

    全てのデバイスのconfiguration(スクリーンサイズやAPI level)に対応したSingle APKを作ることにより、アプリケーションはランタイムで発生するconfiguration changeに柔軟に対応することができます。例えばユーザが端末をドックやHDMI経由で大きなスクリーン(PCモニタ、TVなど)に接続した場合、即座に大きなスクリーンに最適化された表示を行うことができます。ユーザ体験の視点から考えても、あなたのアプリケーションにとってこれは大きなメリットになり得ます。

  • 異なるAndroidデバイス間でのデータリストアの容易性

    ユーザーが現在所持しているデバイスでデータバックアップを有効にしていて、それとは違う設定を持った新しいデバイスを別に購入したとします。セットアップ時にはそのユーザーが前のデバイスに入れていたアプリケーションが新しいデバイスへと自動的にrestore(復元)されます。その時ユーザーが受け取るのは、前のデバイスにリソースが最適化されたアプリケーションなのです。例えば、新しいタブレットでユーザーが受け取るアプリケーションが、開発者であるあなたのタブレットに最適化されたリソースで作られたものであるような状況です。

    このrestoreのプロセスは、異なるAPKが選択されるデバイス間では実行されません。複数のAPKはそれぞれ違ったパーミッションを持つことができるため、ユーザーが前のデバイスで許可したものと違う場合があるからです。このため、Android Marketがrestoreできないアプリケーションもあるでしょう。(もしあなたがマルチプルAPKを採用するのであれば、ユーザーが新しいデバイスに前のデバイスと同じアプリを入れたい時、(APKに互換性がある場合のみ)前のデバイスと全く同じAPKがrestoreされるか、互換性がなくてrestoreされずMarketからダウンロードしなおすか、のどちらかになります)

以下の章ではSingle APKで複数のデバイスに対応するためのやりかたをいくつか紹介します。

Supporting multiple GL textures(複数のGLテクスチャのタイプへの対応)

SIngle APKで複数のGLテクスチャのタイプに対応するためには、そのデバイスが対応しているGLテクスチャのタイプに関する情報を取得し、サーバから適切なリソースを個別にダウンロードするようなしくみが必要です。これはあなたのアプリケーションのサイズを小さく保つためにも必要なやりかたです。

最大限のパフォーマンスと互換性を保つためには、画質に大きな影響がないかぎりETC1テクスチャを使うべきです。しかしながらETC1はラインアートやテキスト表示などのクロマ(彩度)の変化が大きな画像を扱うことはできません。また、アルファ(透過)も未サポートのため、全てのテクスチャに適しているわけではありません。

Single APKの場合は、ETC1テクスチャと非圧縮テクスチャを使うべきです。PVRTCやATITC, DXTCはETC1が使えない場合にのみ使用してください。

以下のサンプルコードは、デバイスが対応している GLSurfaceView.Renderer の圧縮フォーマットを問い合わせるものです。対応している圧縮フォーマットのリストを取得することができます。

public void onSurfaceChanged(GL10 gl, int w, int h) {
   
String extensions = gl.glGetString(GL10.GL_EXTENSIONS);
   
Log.d("ExampleActivity", extensions);
}

Supporting multiple screens(複数のスクリーンへの対応)

あなたのアプリケーションのサイズが50MBを超えない限り、複数のスクリーンへの対応はSingle APKで行うべきです(えーーーー)Android 1.6以降であれば多様なスクリーンサイズおよび密度(density)への対応が可能です。

複数のスクリーンへの対応をさらに良いものにするためには、スクリーンの解像度・サイズ・密度に応じて画像やレイアウトをそれぞれに最適化したものを用意すべきです。

詳細な情報に関しては Supporting Multiple Screens を参照してください。

加えて、Compatibility Package のライブラリの活用も検討してみてください。このライブラリを使うことでHoneycombタブレット等で使われてる Fragments を使用することができます。

Supporting multiple API levels(複数のAPIレベルへの対応)

できるだけ多くのバージョンのAndroidプラットフォームをサポートしたい場合は、妥当な範囲で最も低いバージョンのAPIを利用するとよいでしょう。例えばAndroid 2.1(API Level 7)のものよりも新しいAPIを利用する必要がない場合、そのアプリケーションはAndroidで動くデバイスの95%以上で使えることになります。(バージョンのシェアについてはPlatform Versionsを参照)

Compatibility Packageに含まれるサポートライブラリを使用することで、Android 1.6のような低いバージョンでも、(Android 3.0などの)最新バージョンのAPIを利用することができるようになります。このサポートライブラリは、FragmentsLoadersを始めとして、多数のAPIを含んでいます。Fragment APIが利用できることで、従来のデバイス向けのユーザーインターフェースをタブレットのような大きいデバイスにも最適化することができるのは特筆すべきでしょう。

新しいAndroidバージョンでしか利用できないAPIを使用したいと思うなら、リフレクションの使用も検討してください。 リフレクションを使用することで、現在のデバイスが、そのAPIをサポートするかどうかチェックできます。 チェックしてもしAPIが利用可能でなかった場合、機能を無効にしたり隠したりできます。

そのAPIをサポートするバージョンで動くときだけ新しいAPIを使用する別の方法は、現在のデバイスのAPIレベルをチェックすることです。 すなわち、 SDK_INT の値を取得することで、デバイスによってサポートされたAPIレベルによって異なった実装が可能です。 例えば:


if (android.os.Build.VERSION.SDK_INT >= 11) {
   
// API level 11 (Android 3.0) 以降のAPIをここでつかう
} else {
   
// 古いバージョンをサポートするための何かの処理をここで実行
}
Except as noted, this content is licensed under Apache 2.0. For details and restrictions, see the Content License.
Comments