Android 3.2 API

API レベル: 13

Android 3.2(HONEYCOMB_MR2)は、ユーザーとデベロッパー向けの新機能を追加する増分プラットフォーム リリースです。以下のセクションでは、新機能とデベロッパー向け API の概要について説明します。

デベロッパーの方は、Android SDK のダウンロード可能なコンポーネントとして Android 3.2 プラットフォームをご利用いただけます。ダウンロード可能なプラットフォームには、Android ライブラリとシステム イメージ、エミュレータ スキンのセットなどが含まれています。Android 3.2 向けの開発やテストを開始するには、Android SDK Manager を使用してプラットフォームを SDK にダウンロードします。

プラットフォームの特長

新しいユーザー機能

  • さまざまなタブレット向けに最適化

    Android 3.2 では、幅広いタブレット デバイスで優れたユーザー エクスペリエンスを実現するため、システム全体でさまざまな最適化が行われています。

  • 固定サイズのアプリ向けの互換性ズーム

    Android 3.2 では、新しい互換ズームモードが導入され、大きなデバイスで固定サイズのアプリを表示できるようになりました。新しいモードは、タブレットなどの大きな画面サイズで実行するように設計されていないアプリ向けに、標準の UI ストレッチングに代わるピクセル スケーリングの代替手段を提供します。互換性サポートが必要なアプリでは、システムバーのメニュー アイコンから新しいモードにアクセスできます。

  • SD カードからのメディアの同期

    SD カードをサポートするデバイスでは、メディア ファイルを SD カードから直接、それを使用するアプリに読み込めるようになりました。システム施設は、システム メディアストアからアプリがファイルにアクセスできるようにします。

デベロッパー向けの新機能

  • 画面サポートを管理するための拡張 API

    Android 3.2 では、プラットフォームの画面サポート API に拡張機能が導入され、さまざまな Android 搭載デバイスでアプリの UI を新たな方法で管理できるようになりました。この API には新しいリソース修飾子と新しいマニフェスト属性が用意されており、一般化されたサイズカテゴリに依存するのではなく、さまざまなサイズでアプリをどのように表示するかをより詳細に制御できます。

    プラットフォームには、さまざまな画面サイズのサポートを限定しながら、固定サイズのアプリやアプリで可能な限り最適な表示を実現するため、新しいズーム互換モードが用意されています。このモードは、小さな画面領域に UI をレンダリングし、ディスプレイで利用可能なスペース全体に表示されるように拡大します。画面サポート API とそれが提供するコントロールについて詳しくは、以下のセクションをご覧ください。

API の概要

Screens Support API

Android 3.2 では、新しい画面サポート API が導入され、さまざまな画面サイズでアプリをどのように表示するかを制御できるようになりました。この API は、プラットフォームの一般画面密度モデルを含む既存の画面サポート API を基盤としていますが、汎用的な画面サイズ(large、xlarge など)ではなく、密度非依存のピクセル単位(幅 600 dp や 720 dp など)で測定した寸法に基づいて、特定の画面範囲を正確にターゲットする機能も拡張されています。

アプリの UI を設計する際は、引き続きプラットフォームを利用して密度の抽象化を行うことができます。つまり、アプリはデバイス間の実際のピクセル密度の違いを補正する必要がありません。水平方向または垂直方向のスペースの大きさに応じてアプリ UI を設計できます。プラットフォームは、smallestWidthwidthheight の 3 つの新しい特性を使用して、利用可能なスペースの量を表します。

  • 画面の smallestWidth は基本的な最小サイズで、密度非依存ピクセル(「dp」)単位で測定されます。画面の高さまたは幅のうち、短い方になります。通常、縦向きの画面の場合、smallestWidth はその幅に基づき、横向きの画面では高さに基づきます。いずれの場合も、smallestWidth は画面の固定特性から取得され、値は向きに関係なく変化しません。smallestWidth は、アプリの UI を描画する必要がある最短の幅を表すため、アプリにとって重要です。システムによって予約された画面領域は含まれません。
  • 一方、画面の「幅」と「高さ」は、アプリのレイアウトに現在使用できる水平方向または垂直方向のスペースを「dp」単位で表します。システムによって予約された画面領域は含まれません。画面の幅と高さは、ユーザーが横向きと縦向きを切り替えると変わります。

新しい画面サポート API は、現在の画面の shortestWidth に従ってアプリの UI を管理できるように設計されています。必要に応じて、現在の幅または高さに従って UI を管理することもできます。この目的のために、API には次のツールが用意されています。

  • 新しいリソース修飾子を使用すると、レイアウトやその他のリソースを最小の smallestWidth、幅、高さにターゲティングできます。
  • アプリの最大画面互換性範囲を指定するための新しいマニフェスト属性

また、以前のバージョンのプラットフォームと同様に、アプリは引き続きシステムにクエリを実行し、ランタイムでの UI とリソースの読み込みを管理できます。

新しい API では、smallestWidth、width、height を使って画面をより直接的にターゲットにできるため、さまざまな画面タイプの一般的な特性を理解しておくと役に立ちます。以下の表に「dp」単位で測定した例を示します。

表 1. 密度とサイズ(dp 単位)の一般的なデバイス。

タイプ 密度(一般化) サイズ(dp) smallestWidth(dp)
基準となる電話番号 mdpi 320×480 320
小型タブレット/大型スマートフォン mdpi 480×800 480
7 インチ タブレット mdpi 600x1024 600
10 インチ タブレット mdpi 800×1280 800

以下のセクションでは、新しい画面修飾子とマニフェスト属性について詳しく説明します。画面サポート API の使用方法について詳しくは、複数画面のサポートをご覧ください。

画面の新しいリソース修飾子のサポート

Android 3.2 の新しいリソース修飾子を使用すると、画面サイズの範囲に合わせてレイアウトをより適切にターゲットにできます。この修飾子を使用すると、特定の最小の smallestWidth、現在の幅、または現在の高さ(密度非依存ピクセルで測定)用に設計されたリソース構成を作成できます。

新しい修飾子は次のとおりです。

  • swNNNdp - リソースを使用する最小の smallestWidth を「dp」単位で指定します。前述のとおり、画面の smallestWidth は向きに関係なく一定です。例: sw320dpsw720dpsw720dp
  • wNNNdphNNNdp - リソースを使用する最小の幅または高さを dp 単位で指定します。前述のように、画面の幅と高さは画面の向きに比例し、向きが変わるたびに変化します。例: w320dpw720dph1024dp

必要に応じて、重複する複数のリソース構成を作成することもできます。たとえば、480 dp を超える画面で使用するリソース、600 dp を超える画面、720 dp を超える画面で使用するリソース、その他のリソースをタグ付けできます。特定の画面に対して複数のリソース構成が適格である場合、システムは最も近い構成を選択します。特定の画面で読み込まれるリソースを正確に制御するには、リソースに 1 つの修飾子をタグ付けするか、複数の新規または既存の修飾子を組み合わせることができます。

前述の一般的なディメンションに基づいて、新しい修飾子の使用例をいくつか示します。

res/layout/main_activity.xml   # For phones
res/layout-sw600dp/main_activity.xml   # For 7” tablets
res/layout-sw720dp/main_activity.xml   # For 10” tablets
res/layout-w600dp/main_activity.xml   # Multi-pane when enough width
res/layout-sw600dp-w720dp/main_activity.xml   # For large width

古いバージョンのプラットフォームでは新しい修飾子が無視されるため、必要に応じてこれらの修飾子を組み合わせることで、どのデバイスでもアプリが適切に表示されるようにできます。次に例を示します。

res/layout/main_activity.xml   # For phones
res/layout-xlarge/main_activity.xml   # For pre-3.2 tablets
res/layout-sw600dp/main_activity.xml   # For 3.2 and up tablets

新しい修飾子の使用方法について詳しくは、新しいサイズ修飾子の使用をご覧ください。

画面サイズの互換性を確保するための新しいマニフェスト属性

フレームワークには、さまざまな画面サイズに対するアプリのサポートを管理できる新しい一連の <supports-screens> マニフェスト属性が用意されています。具体的には、システムの新しい画面互換性モードを必要とせずに、アプリの実行対象となる最大画面と最小画面を指定できます。また、アプリを実行する最大画面を指定できます。前述のリソース修飾子と同様に、新しいマニフェスト属性では、smallestWidth で指定されたアプリがサポートする画面の範囲を指定します。

画面サポートの新しいマニフェスト属性は次のとおりです。

  • android:compatibleWidthLimitDp="numDp" - この属性を使用すると、互換モードを必要とせずにアプリを実行できる最大 SmallestWidth を指定できます。現在の画面が指定された値より大きい場合、アプリは通常モードで表示されますが、ユーザーは必要に応じてシステムバーの設定から互換モードに切り替えることができます。
  • android:largestWidthLimitDp="numDp" - この属性を使用すると、アプリを実行するために設計された最大 SmallestWidth を指定できます。現在の画面が指定された値より大きい場合、システムはアプリを強制的に画面互換性モードにして、現在の画面で最適に表示されるようにします。
  • android:requiresSmallestWidthDp="numDp" - この属性を使用すると、アプリを実行できる最小の smallestWidth を指定できます。現在の画面が指定された値より小さい場合、システムはそのアプリと互換性がないとみなしますが、アプリのインストールと実行は阻止しません。

注: Google Play は現在、上記の属性に基づくアプリのフィルタリングを行っていません。フィルタリングのサポートは、今後のプラットフォーム リリースで追加される予定です。画面サイズに基づくフィルタリングが必要なアプリでは、既存の <supports-screens> 属性を使用できます。

新しい属性の使用方法について詳しくは、画面サイズのサポートを宣言するをご覧ください。

画面互換性モード

Android 3.2 には、アプリが実行されている画面よりも大きな画面をサポートしていないことを明示的に宣言するアプリ向けに、新しい画面互換性モードが用意されています。この新しい「ズーム」モードはピクセル スケーリングです。小さな画面領域にアプリをレンダリングしてから、現在の画面全体に収まるようにピクセルを拡大縮小します。

デフォルトでは、画面互換性モードを必要とするアプリ向けに、ユーザー オプションとして画面互換性モードが用意されています。ユーザーは、システムバーにあるコントロールを使用してズームモードのオンとオフを切り替えることができます。

新しい画面互換性モードは、すべてのアプリに適しているとは限らないため、プラットフォームでは、アプリでマニフェスト属性を使用してこのモードを無効にできます。アプリで無効になっている場合、アプリの実行中にユーザーが「ズーム」互換モードを選択することはできません。

注: アプリで互換モードを制御する方法に関する重要な情報については、Android デベロッパー ブログの大画面のアプリ向けの新しいモードをご覧ください。

720p のテレビや同様のデバイス向けの新しい画面密度

720p のテレビなど、中密度の画面で実行されるアプリのニーズを満たすために、Android 3.2 では、おおよその dpi が 213 の新しい汎用密度 tvdpi が導入されています。アプリは densityDpi で新しい密度を照会し、新しい tvdpi 修飾子を使用してテレビなどのデバイスのリソースにタグを付けることができます。次に例を示します。

res/drawable-tvdpi/my_icon.png   # Bitmap for tv density

一般に、アプリケーションはこの密度で動作する必要はありません。720p 画面で出力が必要な場合、UI 要素はプラットフォームによって自動的にスケーリングされます。

UI フレームワーク

  • フラグメント
    • 新しい Fragment.SavedState クラスは、saveFragmentInstanceState() を通じてフラグメント インスタンスから取得した状態情報を保持します。
    • 新しいメソッド saveFragmentInstanceState() は、指定された Fragment の現在のインスタンスの状態を保存します。状態は、後で現在の状態に一致する Fragment の新しいインスタンスを作成するときに使用できます。
    • 新しいメソッド setInitialSavedState() は、Fragment が最初に作成されたときに初期の保存済み状態を設定します。
    • 新しい onViewCreated() コールバック メソッドは、保存済み状態がビューに復元される前に、onCreateView() が返されたことを Fragment に通知します。
    • isDetached() メソッドは、Fragment が UI から明示的にデタッチされたかどうかを判別します。
    • 新しい attach() メソッドと detach() メソッドを使用すると、アプリで UI 内のフラグメントを再アタッチまたはデタッチできます。
    • 新しい setCustomAnimations() オーバーロード メソッドを使用すると、開始/終了オペレーション、特にバックスタックのポップ時に実行する特定のアニメーション リソースを設定できます。既存の実装では、バックスタックをポップする際のフラグメントの動作の違いは考慮されていません。
  • ActivityInfo と ApplicationInfo の画面サイズ情報
  • WindowManager からディスプレイ サイズを取得するためのヘルパー
    • 新しいメソッド getSize()getRectSize() を使用すると、アプリはディスプレイの未加工サイズを取得できます。
  • 新しい公開「ホログラフィック」スタイル
    • プラットフォームでは、テキスト、アクションバー ウィジェット、タブなど、さまざまな「ホログラフィック」スタイルが公開されています。完全なリストについては、R.style をご覧ください。
  • LocalActivityManagerActivityGroupLocalActivityManager のサポートが終了しました
    • 新しいアプリでは、これらのクラスの代わりにフラグメントを使用する必要があります。古いバージョンのプラットフォームで引き続き実行するには、Android SDK に含まれている v4 サポート ライブラリ(互換性ライブラリ)を使用します。v4 サポート ライブラリは、Android 1.6(API レベル 4)までの下位互換性のある Fragment API のバージョンを提供します。
    • Android 3.0(API レベル 11)以降向けに開発されたアプリでは、通常は新しい ActionBar.newTab() とアクションバー領域内にタブを配置するための関連 API を使用して、UI にタブが表示されます。

メディア フレームワーク

  • プラットフォームのメディア プロバイダ(MediaStore)を使用するアプリは、デバイスでサポートされている場合、リムーバブル SD カードから直接メディアデータを読み取れるようになりました。アプリケーションは、MTP API を使用して SD カードファイルを直接操作することもできます。

グラフィック

IME フレームワーク

  • 修飾キーの現在の状態を取得するための新しい getModifiers() メソッドが追加されました。

USB フレームワーク

  • デバイスの未加工の USB 記述子を取得するための新しい getRawDescriptors() メソッドが追加されました。このメソッドを使用すると、上位レベルの API を介して直接サポートされていない記述子にアクセスできます。

ネットワーク

テレフォニー

コア ユーティリティ

  • Parcelable ユーティリティ
  • Binder と IBinder
    • BinderIBinder の新しいメソッド dumpAsync() を使用すると、アプリは指定のファイルにダンプでき、ターゲットが非同期的に実行されます。
    • 新しい IBinder プロトコル トランザクション コード TWEET_TRANSACTION を使用すると、アプリはターゲット オブジェクトにツイートを送信できます。

新機能の定数

プラットフォームは、アプリ マニフェストで宣言できる新しいハードウェア機能定数を追加します。これにより、Google Play などの外部エンティティに、必要なハードウェア機能とソフトウェア機能を通知できます。これらの機能定数とその他の機能定数は、<uses-feature> マニフェスト要素で宣言します。

Google Play は、<uses-feature> 属性に基づいてアプリをフィルタし、要件を満たしているデバイスでのみ利用できるようにします。

  • 横向きまたは縦向きの要件に対応する機能定数

    Android 3.2 には、横向き、縦向き、またはその両方の表示をアプリで必要とするかどうかを指定できる新しい機能定数が導入されています。これらの定数を宣言すると、関連付けられた画面の向きを提供しないデバイスにアプリをインストールしてはいけないことを示します。逆に、一方または両方の定数が宣言されていない場合は、宣言されていない画面の向きをアプリが優先せず、その向きがないデバイスにインストールされる可能性があることを示します。

    通常、横向きと縦向きの両方で適切に機能するアプリの場合、画面の向きの要件を宣言する必要はありません。テレビ用に設計されたアプリなど、主に 1 つの向き向けに設計されたアプリは、定数のいずれかを宣言して、その向きを提供していないデバイスで利用できないようにすることができます。

    マニフェストで宣言されたアクティビティのいずれかが、android:screenOrientation 属性を使用して特定の向きで実行するようリクエストしている場合、アプリにその向きが必要であることも宣言します。

  • その他の機能定数

API 差分レポート

Android 3.2(API レベル 13)におけるすべての API の変更について詳しくは、API 差分レポートをご覧ください。

API レベル

Android 3.2 プラットフォームでは、フレームワーク API の更新版が提供されています。Android 3.2 API には、システム自体に格納されている整数の識別子(13)が割り当てられます。「API レベル」と呼ばれるこの識別子により、アプリをインストールする前に、アプリがシステムに対応しているかどうかを正しく判断できます。

Android 3.2 で導入された API をアプリで使用するには、Android 3.2 SDK プラットフォームに用意されている Android ライブラリに対してアプリをコンパイルする必要があります。必要に応じて、アプリのマニフェストの <uses-sdk> 要素に android:minSdkVersion="13" 属性を追加する必要もあるかもしれません。

詳しくは、API レベルとはをご覧ください。