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 カードからメディア ファイルを直接、その SD カードを使用するアプリに読み込めるようになりました。システム機能によって、アプリがシステム メディアストアからファイルにアクセスできるようになります。
デベロッパー向けの新機能
- 画面サポートを管理するための拡張 API
Android 3.2 では、プラットフォームの画面サポート API の拡張機能が導入され、さまざまな Android 搭載デバイスでアプリ UI を管理する方法が増えています。API には新しいリソース修飾子と新しいマニフェスト属性が含まれており、汎用的なサイズカテゴリに依存することなく、さまざまなサイズでアプリをどのように表示するかをきめ細かく制御できます。
固定サイズのアプリや、さまざまな画面サイズのサポートが制限されたアプリで、可能な限り最適な表示を実現するため、プラットフォームには新しいズーム互換モードも用意されています。このモードは、小さな画面領域で UI をレンダリングし、ディスプレイで使用可能なスペースに合わせて拡大縮小します。画面サポート API と、この API が提供するコントロールの詳細については、以下のセクションをご覧ください。
API の概要
Screens Support API
Android 3.2 では、新しい画面サポート API が導入され、さまざまな画面サイズでアプリをどのように表示するかを制御できるようになりました。この API は、プラットフォームの汎用画面密度モデルを含む既存の画面サポート API を基盤としていますが、一般化された画面サイズ(大、特大など)ではなく、密度に依存しないピクセル単位(幅 600 dp や 720 dp など)で測定した寸法に基づいて、特定の画面範囲を正確にターゲティングする機能を拡張します。
アプリの UI を設計する際、依然としてプラットフォームを利用して密度の抽象化を行うことが可能です。つまり、アプリはデバイス間の実際のピクセル密度の違いを補正する必要がありません。利用可能な水平方向または垂直方向のスペースの量に応じて、アプリの UI をデザインできます。プラットフォームは、使用可能なスペースの量を、smallestWidth、width、height の 3 つの新しい特性を使用して表します。
- 画面の smallestWidth は基本的な最小サイズであり、密度非依存ピクセル(dp)単位で測定されます。画面の高さまたは幅のうち、短い方になります。縦向きの画面の場合、smallestWidth は通常、幅に基づいて設定され、横向きの画面では高さに基づきます。すべての場合、smallestWidth は画面の固定特性から導出され、値は向きに関係なく変化しません。smallestWidth は、アプリの UI を描画する必要がある最小幅を表すため、アプリにとって重要です。システムによって予約された画面領域は含まれません。
- これに対して、画面の「幅」と「高さ」は、アプリのレイアウトに使用可能な現在水平方向または垂直方向のスペースを「dp」単位で表します。システムによって予約されている画面領域は含みません。ユーザーが横向きと縦向きを切り替えると、画面の幅と高さが変化します。
新しい画面サポート API は、現在の画面の smallestWidth に従ってアプリの UI を管理できるように設計されています。必要に応じて、現在の幅または高さに従って UI を管理することもできます。この目的のために、API には次のツールが用意されています。
- レイアウトやその他のリソースを最小の smallestWidth、幅、または高さにターゲティングするための新しいリソース修飾子。
- アプリの最大画面互換性範囲を指定するための新しいマニフェスト属性
また、以前のバージョンのプラットフォームと同様に、引き続きアプリにクエリを実行し、実行時に UI やリソースの読み込みを管理できます。
新しい API では、smallestWidth、width、height を使ってより直接的に画面をターゲットにできるため、さまざまな画面タイプの典型的な特性を理解するのに役立ちます。「dp」単位で測定した例を以下の表に示します。
タイプ | 密度(一般化) | サイズ(dp) | minimumestWidth(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 は、向きに関係なく一定です。例: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 では、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 の画面サイズ情報
ActivityInfo
はconfigChanges
にビットマスクとしてCONFIG_SCREEN_SIZE
とCONFIG_SMALLEST_SCREEN_SIZE
を追加します。ビットは、アクティビティ自体が画面サイズと最小画面サイズを処理できるかどうかを示します。ApplicationInfo
は、アプリ マニフェスト ファイル内の対応する<supports-screens>
属性から派生したlargestWidthLimitDp
フィールド、compatibleWidthLimitDp
フィールド、requiresSmallestWidthDp
フィールドを追加します。
- WindowManager からディスプレイ サイズを取得するためのヘルパー
- 新しいメソッド
getSize()
とgetRectSize()
により、アプリがディスプレイの未加工のサイズを取得できるようになりました。
- 新しいメソッド
- 新しい公開「ホログラフィック」スタイル
- 現在、プラットフォームでは、テキスト、アクションバー ウィジェット、タブなど、さまざまな公開「ホログラフィック」スタイルが公開されています。完全なリストについては、
R.style
をご覧ください。
- 現在、プラットフォームでは、テキスト、アクションバー ウィジェット、タブなど、さまざまな公開「ホログラフィック」スタイルが公開されています。完全なリストについては、
LocalActivityManager
、ActivityGroup
、LocalActivityManager
のサポートが終了しました。- 新しいアプリでは、これらのクラスではなく Fragment を使用する必要があります。古いバージョンのプラットフォームで引き続き実行するには、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 フレームワーク
- デバイスの RAW 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 レベルとはをご覧ください。