このページは Cloud Translation API によって翻訳されました。

Android 3.2 API

API レベル: 13

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

デベロッパーは、Android 3.2 プラットフォームを Android SDK のダウンロード可能なコンポーネントとして利用できます。ダウンロード可能なプラットフォームには、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 など）ではなく、密度に依存しないピクセル単位（幅 600dp や 720dp など）で測定される寸法で特定の画面範囲を正確にターゲティングできる機能が追加されています。

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

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

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

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

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

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

表 1. 一般的なデバイス（密度とサイズは dp 単位）。

タイプ	密度（一般化）	サイズ（dp）	SmallestWidth（dp）
基準となるスマートフォン	mdpi	320×480	320
小型タブレット/大型スマートフォン	mdpi	480x800	480
7 インチタブレット	mdpi	600x1024	600
10 インチタブレット	mdpi	800x1280	800

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

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

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

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

swNNNdp - リソースを使用する最小の smallestWidth を「dp」単位で指定します。前述のとおり、画面の smallestWidth は、向きに関係なく一定です。例: sw320dp、sw720dp、sw720dp。
wNNNdp と hNNNdp - リソースを使用する最小の幅または高さを「dp」単位で指定します。前述のように、画面の幅と高さは画面の向きに相対的であり、向きが変わるたびに変化します。例: w320dp、w720dp、h1024dp。

必要に応じて、重複する複数のリソース構成を作成することもできます。たとえば、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 では、新しい汎用密度 tvdpi が導入されました。この密度は dpi で約 213 です。アプリは 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() が返されたことをフラグメントに通知します。
- isDetached() メソッドは、フラグメントが UI から明示的にデタッチされているかどうかを判断します。
- 新しい attach() メソッドと detach() メソッドにより、アプリは UI 内のフラグメントを再アタッチまたはアタッチ解除できます。
- 新しい setCustomAnimations() オーバーロードメソッドを使用すると、開始/終了オペレーション、特にバックスタックをポップするときに実行する特定のアニメーションリソースを設定できます。既存の実装では、バックスタックをポップする際のフラグメントの動作の違いを考慮していません。
ActivityInfo と ApplicationInfo の画面サイズ情報
- ActivityInfo は、configChanges にビットマスクとして CONFIG_SCREEN_SIZE と CONFIG_SMALLEST_SCREEN_SIZE を追加します。このビットは、アクティビティ自体が画面サイズと最小画面サイズを処理できるかどうかを示します。
- ApplicationInfo は、アプリケーションマニフェストファイル内の対応する <supports-screens> 属性から派生した largestWidthLimitDp、compatibleWidthLimitDp、requiresSmallestWidthDp フィールドを追加します。
WindowManager からディスプレイサイズを取得するためのヘルパー。
- 新しいメソッド getSize() と getRectSize() を使用すると、アプリはディスプレイの未加工サイズを取得できます。
新しい公開「ホログラフィック」スタイル
- プラットフォームでは、テキスト、アクションバーウィジェット、タブなど、さまざまな公開「ホログラフィック」スタイルが公開されています。完全なリストについては、R.style をご覧ください。
LocalActivityManager、ActivityGroup、LocalActivityManager のサポートが終了しました
- 新しいアプリでは、これらのクラスではなく Fragments を使用する必要があります。古いバージョンのプラットフォームで引き続き実行するには、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 カードのファイルを直接操作することもできます。

グラフィック

Point と PointF の Parcelable ユーティリティ
- Point クラスと PointF クラスに、Parcelable インターフェースとユーティリティメソッド describeContents()、readFromParcel()、writeToParcel() が追加されました。

IME フレームワーク

修飾キーの現在の状態を取得するための新しい getModifiers() メソッド。

USB フレームワーク

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

ネットワーク

ネットワークタイプの定数
- ConnectivityManager は定数 TYPE_ETHERNET と TYPE_BLUETOOTH を追加します。

電話

新しい NETWORK_TYPE_HSPAP ネットワークタイプの定数。

コアユーティリティ

Parcelable ユーティリティ
- 新しいインターフェース Parcelable.ClassLoaderCreator により、アプリケーションはオブジェクトが作成されている ClassLoader を受信できます。
- ParcelFileDescriptor オブジェクトを管理するための新しい adoptFd、dup()、fromFd()。
Binder と IBinder
- Binder と IBinder の新しいメソッド dumpAsync() を使用すると、アプリケーションは指定したファイルにダンプし、ターゲットが非同期で実行されるようにできます。
- 新しい IBinder プロトコルトランザクションコード TWEET_TRANSACTION を使用すると、アプリケーションはターゲットオブジェクトにツイートを送信できます。

新しい特徴定数

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

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

横向きまたは縦向きの要件に対応する機能定数
Android 3.2 では、横向き、縦向き、またはその両方での表示が必要かどうかをアプリで指定できる新しい機能定数が導入されました。これらの定数を宣言すると、関連する画面の向きに対応していないデバイスにアプリをインストールできないことを示します。一方、定数の一つまたは両方が宣言されていない場合、宣言されていない画面の向きに対する設定がアプリにないことを示します。この場合、その画面の向きに対応していないデバイスにアプリがインストールされる可能性があります。
- android.hardware.screen.landscape - アプリは横向きで表示する必要があります。
- android.hardware.screen.portrait - アプリは縦向きで表示する必要があります。
通常、横向きと縦向きの両方で適切に動作する一般的なアプリでは、向きの要件を宣言する必要はありません。むしろ、テレビ向けに設計されたアプリなど、主に 1 つの向き向けに設計されたアプリでは、いずれかの定数を宣言して、その向きをサポートしていないデバイスでは使用できないようにすることができます。

マニフェストで宣言されているアクティビティのいずれかが、android:screenOrientation 属性を使用して、特定の向きでの実行をリクエストした場合、アプリにその向きが必要であることも宣言します。
その他の特徴定数
- android.hardware.faketouch.multitouch.distinct - 2 つ以上の点を個別にトラッキングするエミュレートされたマルチタッチ入力のサポートがアプリに必要です。
- android.hardware.faketouch.multitouch.jazzhand - アプリは、5 つ以上の点を個別にトラッキングするエミュレートされたマルチタップ入力をサポートする必要があります。

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 レベルとはをご覧ください。

Android 3.2 API コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。