Android 4.0 API

API レベル: 14

Android 4.0（ICE_CREAM_SANDWICH）はプラットフォームのメジャー リリースで、ユーザーとアプリ デベロッパー向けにさまざまな新機能が追加されています。Android 4.0 は、以下で説明するすべての新機能と API に加え、Android 3.x の幅広い API とホログラフィック テーマを小さな画面で利用できるため、重要なプラットフォーム リリースです。アプリ デベロッパーは単一のプラットフォームと統合 API フレームワークを使用でき、単一の APK でアプリを開発して公開できるようになりました。これにより、ハンドセットやタブレットなど、同じバージョンの Android 4.0（API レベル 14）以降を搭載している場合でも、最適なユーザー エクスペリエンスを実現できます。

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

API の概要

以下のセクションでは、Android 4.0 の新しい API の技術的な概要について説明します。

連絡先プロバイダのソーシャル API

ContactsContract プロバイダによって定義される連絡先 API は、デバイス所有者の個人用プロファイルや、デバイスにインストールされているソーシャル ネットワークにユーザーが個々の連絡先を招待する機能など、新しいソーシャル向けの機能をサポートするように拡張されました。

ユーザー プロフィール

Android には、ContactsContract.Profile テーブルで定義されているデバイス オーナーを表す個人用プロファイルが追加されました。ユーザー ID を維持するソーシャル アプリは、ContactsContract.Profile 内に新しい ContactsContract.RawContacts エントリを作成することで、ユーザーのプロファイル データに提供できます。つまり、デバイス ユーザーを表す未加工連絡先は、ContactsContract.RawContacts URI で定義された従来の未加工連絡先テーブルには属しません。代わりに、CONTENT_RAW_CONTACTS_URI にあるテーブルにプロファイル未加工連絡先を追加する必要があります。このテーブルの未加工の連絡先は、「Me」というラベルの付いた、ユーザーに表示される単一のプロファイルに集約されます。

プロファイルに新しい未加工連絡先を追加するには、android.Manifest.permission#WRITE_PROFILE 権限が必要です。同様に、プロファイル テーブルから読み取るには、android.Manifest.permission#READ_PROFILE 権限をリクエストする必要があります。ただし、ほとんどのアプリでは、プロファイルにデータを提供する場合でも、ユーザー プロファイルを読み取る必要はありません。ユーザー プロファイルの読み取りは機密情報に関わる権限であるため、ユーザーはこの読み取りをリクエストするアプリに懐疑的であると考えられます。

招待インテント

INVITE_CONTACT インテントのアクションを使用すると、アプリは、ユーザーがソーシャル ネットワークへの連絡先の追加を希望していることを示すアクションを呼び出すことができます。受信したアプリは、これを使用して、指定された連絡先をそのソーシャル ネットワークに招待します。ほとんどのアプリは、このオペレーションの受信側にあります。たとえば、ユーザーの連絡先情報に表示されている特定のソーシャル アプリに対してユーザーが [接続を追加] を選択すると、組み込みの People アプリが招待インテントを呼び出します。

アプリが [接続を追加] リストに表示されるようにするには、ソーシャル ネットワークの連絡先情報を同期するための同期アダプターをアプリで提供する必要があります。次に、アプリの同期構成ファイルに inviteContactActivity 属性を追加し、招待インテントの送信時にシステムが開始するアクティビティの完全修飾名を指定して、アプリが INVITE_CONTACT インテントに応答することをシステムに示す必要があります。開始されたアクティビティは、インテントのデータから対象の連絡先の URI を取得し、その連絡先をネットワークに招待したり、ユーザーをユーザーの接続に追加したりするために必要な処理を実行できます。

サイズの大きい写真

Android で連絡先の高解像度の写真を使用できるようになりました。写真を連絡先レコードに push すると、以前と同様に 96x96 のサムネイルと、新しいファイルベースの写真ストアに保存される 256x256 の「表示写真」の両方に写真を処理します（システムによって選択される正確なサイズは今後変わる可能性があります）。大きな写真を連絡先に追加するには、データ行の通常の PHOTO 列に大きな写真を配置します。これにより、システムが適切なサムネイルを処理して写真レコードを表示します。

連絡先の使用状況に関するフィードバック

新しい ContactsContract.DataUsageFeedback API を使用すると、ユーザーが特定の連絡手段を使用した頻度（各電話番号やメールアドレスの使用頻度など）を追跡できます。この情報は、各ユーザーに関連付けられた各連絡方法のランキングを改善し、各ユーザーへの連絡方法を改善するのに役立ちます。

カレンダー プロバイダ

新しいカレンダー API を使用すると、カレンダー プロバイダに保存されているカレンダー、予定、参加者、リマインダー、アラートの読み取り、追加、変更、削除を行うことができます。

さまざまなアプリやウィジェットで、これらの API を使用してカレンダーの予定を読み取り、変更できます。ただし、同期アダプターを使用すると、他のカレンダー サービスのカレンダーをカレンダー プロバイダと同期し、ユーザーのすべての予定を 1 か所で管理できます。たとえば、Google カレンダーの予定は、Google Calendar Sync Adapter によってカレンダー プロバイダと同期され、Android に組み込まれたカレンダー アプリでこれらの予定を表示できます。

カレンダー プロバイダ内のカレンダーとイベント関連情報のデータモデルは、CalendarContract によって定義されます。ユーザーのカレンダー データはすべて、CalendarContract のさまざまなサブクラスで定義されたいくつかのテーブルに保存されます。

  • CalendarContract.Calendars テーブルはカレンダー固有の情報を保持します。このテーブルの各行には、名前、色、同期情報など、1 つのカレンダーの詳細が格納されています。
  • CalendarContract.Events テーブルは、イベント固有の情報を保持します。このテーブルの各行には、イベントのタイトル、場所、開始時間、終了時間など、1 つのイベントに関する情報が含まれています。イベントは 1 回だけ発生することも、複数回発生することもあります。参加者、リマインダー、拡張プロパティは別々のテーブルに保存され、イベントの _ID を使用してイベントにリンクされます。
  • CalendarContract.Instances テーブルは、イベントが発生した開始時刻と終了時刻を保持します。このテーブルの各行は 1 つの発生を表します。1 回限りのイベントの場合、インスタンスとイベントの 1 対 1 のマッピングがあります。定期的なイベントの場合は、そのイベントの複数回の発生に対応する複数の行が自動的に生成されます。
  • CalendarContract.Attendees テーブルは、イベントの参加者またはゲストの情報を保持します。各行は、予定の 1 人のゲストを表します。ゲストのタイプと、イベントに対するユーザーの応答を指定します。
  • CalendarContract.Reminders テーブルは、アラート/通知データを保持します。各行は、イベントに対する 1 つのアラートを表します。1 つの予定に複数のリマインダーを設定できます。イベントあたりのリマインダーの数は MAX_REMINDERS で指定されます。これは、特定のカレンダーを所有する同期アダプターによって設定されます。リマインダーは、イベントがスケジュールされる前に分単位で指定され、アラート、メール、SMS を使用してユーザーにリマインドするなどのアラーム方法を指定します。
  • CalendarContract.ExtendedProperties テーブルは、同期アダプターで使用される不透明なデータ フィールドを保持します。プロバイダは、このテーブルのアイテムに対してアクションは行いませんが、関連するイベントが削除されたときにアイテムを削除します。

カレンダー プロバイダを使用してユーザーのカレンダー データにアクセスするには、アプリケーションから READ_CALENDAR 権限（読み取りアクセス）と WRITE_CALENDAR（書き込みアクセス）をリクエストする必要があります。

イベントの意図

ユーザーのカレンダーに予定を追加するだけの場合は、Events.CONTENT_URI で定義されたデータを含む ACTION_INSERT インテントを使用して、新しい予定を作成するアクティビティをカレンダー アプリで開始できます。このインテントを使用するのに権限は必要なく、次のエクストラを使用してイベントの詳細を指定できます。

ボイスメール プロバイダ

新しいボイスメール プロバイダを使用すると、アプリケーションでボイスメールをデバイスに追加して、ユーザーのすべてのボイスメールを 1 つの視覚的なプレゼンテーションで表示できます。たとえば、ユーザーが複数のボイスメール ソースを持っている可能性があります。たとえば、スマートフォンのサービス プロバイダからのものもあれば、VoIP またはその他の代替の音声サービスからのものも 1 つです。これらのアプリは、Voicemail Provider API を使用してボイスメールをデバイスに追加できます。その後、組み込みの電話アプリケーションによって、すべてのボイスメールが統合されたプレゼンテーションでユーザーに提示されます。すべてのボイスメールを読み取ることができるアプリはシステムの電話アプリのみですが、ボイスメールを提供する各アプリは、システムに追加されたボイスメールを読み取ることができます（他のサービスのボイスメールを読み取ることはできません）。

この API では現在、サードパーティ アプリがシステムからすべてのボイスメールを読み取ることができないため、ボイスメール API を使用するサードパーティ アプリは、ユーザーにボイスメールを配信するサードパーティ アプリのみを使用する必要があります。

VoicemailContract クラスは、ボイスメール プロバイダのコンテンツ プロバイダを定義します。サブクラス VoicemailContract.Voicemails と VoicemailContract.Status は、アプリがデバイスのストレージにボイスメール データを挿入できるテーブルを提供します。ボイスメール プロバイダ アプリの例については、ボイスメール プロバイダのデモをご覧ください。

マルチメディア

Android 4.0 には、写真、動画、音楽などのメディアを操作するアプリ用の新しい API がいくつか追加されています。

メディア効果

新しいメディア エフェクト フレームワークを使用すると、画像や動画にさまざまな視覚効果を適用できます。たとえば、画像効果を使用すると、赤目の修正、画像のグレースケールへの変換、明るさの調整、彩度の調整、画像の回転、魚眼効果の適用などを簡単に行うことができます。システムは、最大限のパフォーマンスを得るために、GPU ですべてのエフェクト処理を実行します。

パフォーマンスを最大化するには、エフェクトが OpenGL テクスチャに直接適用されるため、アプリでエフェクト API を使用するには、有効な OpenGL コンテキストが必要です。効果を適用するテクスチャは、ビットマップ、動画、さらにはカメラのものになります。ただし、テクスチャには次のような一定の制限があります。

  1. GL_TEXTURE_2D テクスチャ画像にバインドする必要があります。
  2. 少なくとも 1 つの mipmap レベルを含める必要があります

Effect オブジェクトは、画像フレームに適用できる単一のメディア効果を定義します。Effect を作成するための基本的なワークフローは次のとおりです。

  1. OpenGL ES 2.0 コンテキストから EffectContext.createWithCurrentGlContext() を呼び出します。
  2. 返された EffectContext を使用して EffectContext.getFactory() を呼び出します。これにより、EffectFactory のインスタンスが返されます。
  3. createEffect() を呼び出して、@link android.media.effect.EffectFactory} のエフェクト名（EFFECT_FISHEYE や EFFECT_VIGNETTE など）を渡します。

エフェクトのパラメータを調整するには、setParameter() を呼び出してパラメータ名とパラメータ値を渡します。エフェクトのタイプごとに、さまざまなパラメータを指定できます。パラメータはエフェクト名とともに記載されています。たとえば、EFFECT_FISHEYE には歪みの scale のパラメータが 1 つあります。

テクスチャに効果を適用するには、Effect に対して apply() を呼び出し、入力テクスチャ、幅と高さ、出力テクスチャを渡します。入力テクスチャは GL_TEXTURE_2D テクスチャ画像にバインドする必要があります（通常は glTexImage2D() 関数を呼び出して行います）。mipmap レベルは複数指定できます。出力テクスチャがテクスチャ画像にバインドされていない場合、エフェクトによって自動的に GL_TEXTURE_2D として、入力と同じサイズの mipmap レベル（0）でバインドされます。

EffectFactory にリストされているエフェクトはすべてサポートが保証されています。ただし、外部ライブラリから利用できる追加エフェクトの中には、すべてのデバイスでサポートされているわけではないため、まず isEffectSupported() を呼び出して、外部ライブラリからの必要なエフェクトがサポートされているかどうかを確認する必要があります。

リモート コントロール クライアント

新しい RemoteControlClient を使用すると、メディア プレーヤーはデバイスのロック画面などのリモコン クライアントから再生コントロールを有効にできます。メディア プレーヤーは、トラック情報やアルバムアートなど、現在再生中のメディアに関する情報をリモコンに表示することもできます。

メディア プレーヤーでリモート コントロール クライアントを有効にするには、コンストラクタを使用して RemoteControlClient をインスタンス化し、ACTION_MEDIA_BUTTON をブロードキャストする PendingIntent を渡します。また、このインテントでは、ACTION_MEDIA_BUTTON イベントを処理するアプリ内の明示的な BroadcastReceiver コンポーネントも宣言する必要があります。

プレーヤーが処理できるメディア コントロール入力を宣言するには、RemoteControlClient で setTransportControlFlags() を呼び出して、FLAG_KEY_MEDIA_PREVIOUS や FLAG_KEY_MEDIA_NEXT などの一連の FLAG_KEY_MEDIA_* フラグを渡す必要があります。

次に、RemoteControlClient を MediaManager.registerRemoteControlClient() に渡して登録する必要があります。登録が完了すると、RemoteControlClient をインスタンス化したときに宣言したブロードキャスト レシーバは、リモコンのボタンが押されたときに ACTION_MEDIA_BUTTON イベントを受信します。受け取ったインテントには、押されたメディアキーの KeyEvent が含まれます。これは、getParcelableExtra(Intent.EXTRA_KEY_EVENT) を使用してインテントから取得できます。

再生中のメディアに関する情報をリモコンに表示するには、editMetaData() を呼び出して、返された RemoteControlClient.MetadataEditor にメタデータを追加します。メディアのアートワーク、経過時間などの数値情報、トラックのタイトルなどのテキスト情報用のビットマップを指定できます。使用可能なキーについては、MediaMetadataRetriever の METADATA_KEY_* フラグをご覧ください。

実装例については、ランダム音楽プレーヤーをご覧ください。このプレーヤーは、Android 2.1 まで遡ってデバイスをサポートしながら、Android 4.0 デバイスでリモコン クライアントを有効にするための互換性ロジックを提供します。

メディア プレーヤー

  • MediaPlayer からオンライン メディアをストリーミングするには、INTERNET 権限が必要になりました。MediaPlayer を使用してインターネットからコンテンツを再生する場合は、必ず INTERNET 権限をマニフェストに追加してください。そうしないと、Android 4.0 以降、メディアの再生が機能しなくなります。
  • setSurface() を使用すると、動画シンクとして動作するように Surface を定義できます。
  • setDataSource() を使用すると、リクエストで追加の HTTP ヘッダーを送信できます。これは、HTTP(S) ライブ ストリーミングで役立ちます。
  • HTTP(S) ライブ配信で HTTP Cookie が考慮されるようになりました

メディアの種類

Android 4.0 では、次のサポートが追加されています。

  • HTTP/HTTPS Live Streaming Protocol バージョン 3
  • ADTS raw AAC 音声エンコード
  • WebP 画像
  • Matroska 動画

詳しくは、サポートされているメディア形式をご覧ください。

カメラ

Camera クラスに、顔を検出し、フォーカスと測光領域を制御するための API が追加されました。

顔検出

Android の顔検出 API を使用して、カメラアプリの機能を強化できるようになりました。この API は、被写体の顔を検出するだけでなく、目や口などの特定の顔の特徴も検出します。

カメラアプリで顔を検出するには、setFaceDetectionListener() を呼び出して Camera.FaceDetectionListener を登録する必要があります。その後、startFaceDetection() を呼び出してカメラ サーフェスを開始し、顔の検出を開始できます。

カメラシーンから 1 つ以上の顔が検出されると、Camera.FaceDetectionListener の実装で onFaceDetection() コールバック（Camera.Face オブジェクトの配列を含む）が呼び出されます。

Camera.Face クラスのインスタンスは、検出された顔に関する次のようなさまざまな情報を提供します。

  • Rect: カメラの現在の画角を基準として顔の境界を指定します。
  • オブジェクトが人間の顔であることの信頼度を示す 1 ～ 100 の整数
  • 複数の顔を追跡できる一意の ID
  • 目と口の位置を示す複数の Point オブジェクト

注: 一部のデバイスでは顔検出がサポートされていない可能性があるため、getMaxNumDetectedFaces() を呼び出して戻り値が 0 より大きいことを確認する必要があります。また、デバイスによっては目と口の識別に対応していない場合があります。この場合、Camera.Face オブジェクトのこれらのフィールドは null になります。

フォーカス エリアと測光エリア

カメラアプリで、カメラがフォーカスに使用する領域、ホワイト バランスと自動露出測光に使用する領域を制御できるようになりました。どちらの機能も、新しい Camera.Area クラスを使用して、カメラの現在のビューの中でフォーカスまたは計測する領域を指定します。Camera.Area クラスのインスタンスは、領域の境界を Rect と領域の重み（考慮する他の領域に対するその領域の重要度のレベルを表す）で整数で定義します。

フォーカス エリアまたは測光エリアを設定する前に、まずそれぞれ getMaxNumFocusAreas() または getMaxNumMeteringAreas() を呼び出す必要があります。ゼロが返される場合、デバイスは対応する機能をサポートしていません。

使用するフォーカス エリアまたは測光エリアを指定するには、setFocusAreas() または setMeteringAreas() を呼び出します。それぞれ、フォーカスや測光の対象にする領域を示す Camera.Area オブジェクトの List を取ります。たとえば、プレビューの領域をタップすることでユーザーがフォーカス領域を設定できる機能を実装すると、それを Camera.Area オブジェクトに変換し、シーンのその領域にカメラのフォーカスを合わせるようリクエストできます。その領域でのピントや露出は、その領域内のシーンの変化に伴って継続的に更新されます。

写真の連続オートフォーカス

写真の撮影時に連続オートフォーカス（CAF）を有効にできるようになりました。カメラアプリで CAF を有効にするには、FOCUS_MODE_CONTINUOUS_PICTURE を setFocusMode() に渡します。写真を撮影する準備ができたら、autoFocus() を呼び出します。Camera.AutoFocusCallback は、フォーカスが得られたかどうかを示すコールバックをすぐに受け取ります。コールバックの受信後に CAF を再開するには、cancelAutoFocus() を呼び出す必要があります。

注: 動画をキャプチャする際は、API レベル 9 で追加された FOCUS_MODE_CONTINUOUS_VIDEO を使用して連続オートフォーカスもサポートされます。

その他のカメラ機能

  • 動画の録画中に takePicture() を呼び出して、動画セッションを中断することなく写真を保存できるようになりました。その前に、isVideoSnapshotSupported() を呼び出して、ハードウェアでサポートされていることを確認する必要があります。
  • setAutoExposureLock() と setAutoWhiteBalanceLock() を使用して自動露出とホワイト バランスをロックし、これらのプロパティが変更されないようにできるようになりました。
  • カメラ プレビューの実行中に、setDisplayOrientation() を呼び出せるようになりました。以前は、プレビューの開始前にのみこれを呼び出すことができましたが、いつでも向きを変更できるようになりました。

カメラ ブロードキャスト インテント

  • Camera.ACTION_NEW_PICTURE: ユーザーが新しい写真を撮影したことを示します。写真がキャプチャされると、組み込みのカメラアプリがこのブロードキャストを呼び出します。サードパーティのカメラアプリも、写真のキャプチャ後にこのインテントをブロードキャストする必要があります。
  • Camera.ACTION_NEW_VIDEO: ユーザーが新しい動画をキャプチャしたことを示します。組み込みのカメラアプリは、動画の撮影後にこのブロードキャストを呼び出します。サードパーティのカメラアプリも、動画の撮影後にこのインテントをブロードキャストする必要があります。

Android ビーム（NFC による NDEF プッシュ）

Android ビームは新しい NFC 機能で、デバイス間で NDEF メッセージを送信できます（「NDEF プッシュ」とも呼ばれるプロセス）。データ転送は、Android ビームをサポートする 2 台の Android 搭載デバイスが近い位置（約 4 cm）にあり、通常は背中が触れているときに開始されます。NDEF メッセージ内のデータには、デバイス間で共有する任意のデータを含めることができます。たとえば、連絡帳アプリでは連絡先、YouTube は動画を共有し、ブラウザは Android ビームを使用して URL を共有します。

Android ビームを使用してデバイス間でデータを送信するには、NdefMessage を作成して、アクティビティがフォアグラウンドにあるときに共有する情報を含める必要があります。次に、次のいずれかの方法で NdefMessage をシステムに渡す必要があります。

  • アクティビティ内でプッシュする NdefMessage を 1 つ定義します。

    送信するメッセージを設定するには、いつでも setNdefPushMessage() を呼び出します。たとえば、このメソッドを呼び出し、アクティビティの onCreate() メソッドで NdefMessage に渡します。次に、アクティビティがフォアグラウンドにあるときに、別のデバイスで Android ビームが有効になるたびに、システムが NdefMessage を他のデバイスに送信します。

  • Android ビームの開始時にプッシュする NdefMessage を定義します。

    NfcAdapter.CreateNdefMessageCallback を実装します。これにより、createNdefMessage() メソッドの実装で、送信する NdefMessage が返されます。次に、NfcAdapter.CreateNdefMessageCallback の実装を setNdefPushMessageCallback() に渡します。

    この場合、アクティビティがフォアグラウンドにあるときに、別のデバイスで Android ビームを有効にすると、システムは createNdefMessage() を呼び出して、送信する NdefMessage を取得します。これにより、アクティビティの存続期間を通じてメッセージの内容が変化する可能性がある場合に、Android ビームが開始された後にのみ配信されるように NdefMessage を定義できます。

システムが他のデバイスに NDEF メッセージを正常に配信した後で特定のコードを実行する場合は、NfcAdapter.OnNdefPushCompleteCallback を実装し、setNdefPushCompleteCallback() で設定します。メッセージが配信されると、onNdefPushComplete() が呼び出されます。

受信側デバイスでは、通常の NFC タグと同様の方法で NDEF プッシュ メッセージがシステムに送信されます。システムは、ACTION_NDEF_DISCOVERED アクションでインテントを呼び出してアクティビティを開始します。このとき、NdefMessage の最初の NdefRecord に従って URL または MIME タイプが設定されます。応答するアクティビティについて、アプリで扱う URL または MIME タイプのインテント フィルタを宣言できます。タグ ディスパッチの詳細については、NFC デベロッパー ガイドをご覧ください。

NdefMessage に URI を渡す場合、コンビニエンス メソッド createUri を使用して、文字列または Uri オブジェクトに基づいて新しい NdefRecord を作成できるようになりました。URI が、Android ビーム イベント中にアプリにも受信されるようにする特別な形式の場合、着信 NDEF メッセージを受信するには、同じ URI スキームを使用してアクティビティのインテント フィルタを作成する必要があります。

また、他のアプリが同じインテントのアクションに対してフィルタする場合でも、アプリが受信する NDEF メッセージを処理できるように、NdefMessage で「Android アプリ レコード」を渡す必要があります。Android アプリ レコードを作成するには、createApplicationRecord() を呼び出してアプリのパッケージ名を渡します。他のデバイスがアプリ レコードを含む NDEF メッセージを受信し、指定されたインテントを処理するアクティビティが複数のアプリに含まれている場合、システムは常に（一致するアプリ レコードに基づいて）アプリ内のアクティビティにメッセージを配信します。対象デバイスにアプリがインストールされていない場合、システムは Android アプリ レコードを使用して Google Play を起動し、アプリをインストールするためにユーザーをアプリに誘導します。

アプリで NFC API を使用して NDEF プッシュ メッセージングを実行しない場合、Android はデフォルトの動作を行います。一方のデバイスでアプリがフォアグラウンドにあり、別の Android 搭載デバイスで Android ビームが呼び出されると、もう一方のデバイスは、アプリを識別する Android アプリ レコードを含む NDEF メッセージを受信します。受信側のデバイスにアプリがインストールされている場合は、システムがそのアプリを起動します。インストールされていない場合、Google Play が開いて、アプリをインストールするためのアプリに移動します。

Android ビームやその他の NFC 機能について詳しくは、NFC の基本のデベロッパー ガイドをご覧ください。Android ビームを使用するサンプルコードについては、Android Beam のデモをご覧ください。

Wi-Fi P2P

Android では、Wi-Fi Alliance の Wi-Fi DirectTM 認定プログラムに準拠しており、Android 搭載デバイスと他のデバイスタイプとの間で、アクセス ポイントやインターネット接続を必要としない Wi-Fi ピアツーピア（P2P）接続がサポートされるようになりました。Android フレームワークには、一連の Wi-Fi P2P API が用意されており、各デバイスが Wi-Fi P2P をサポートしている場合に他のデバイスを検出して接続し、Bluetooth 接続よりもはるかに長い距離にわたって高速な接続を介して通信できます。

新しいパッケージ android.net.wifi.p2p には、Wi-Fi でピアツーピア接続を実行するためのすべての API が含まれています。操作する必要があるプライマリ クラスは WifiP2pManager です。このクラスは getSystemService(WIFI_P2P_SERVICE) を呼び出して取得できます。WifiP2pManager には、次のことができる API が含まれています。

  • initialize() を呼び出して、P2P 接続用にアプリケーションを初期化する
  • discoverPeers() に発信して付近のデバイスを検出します
  • connect() を呼び出して P2P 接続を開始します
  • その他

他にも、次のようなインターフェースとクラスが必要です。

  • WifiP2pManager.ActionListener インターフェースを使用すると、ピアの検出やピアへの接続などのオペレーションの成功または失敗時にコールバックを受信できます。
  • WifiP2pManager.PeerListListener インターフェースを使用すると、検出されたピアに関する情報を受信できます。コールバックは WifiP2pDeviceList を提供します。これにより、範囲内の各デバイスの WifiP2pDevice オブジェクトを取得し、デバイス名、アドレス、デバイスタイプ、デバイスがサポートする WPS 設定などの情報を取得できます。
  • WifiP2pManager.GroupInfoListener インターフェースを使用すると、P2P グループに関する情報を受信できます。コールバックは、オーナー、ネットワーク名、パスフレーズなどのグループ情報を提供する WifiP2pGroup オブジェクトを提供します。
  • WifiP2pManager.ConnectionInfoListener インターフェースを使用すると、現在の接続に関する情報を受け取ることができます。このコールバックは WifiP2pInfo オブジェクトを提供します。このオブジェクトには、グループが形成されたかどうかや、誰がグループのオーナーかなどの情報が含まれています。

Wi-Fi P2P API を使用するには、アプリで次のユーザー権限をリクエストする必要があります。

  • ACCESS_WIFI_STATE
  • CHANGE_WIFI_STATE
  • INTERNET（アプリは技術的にはインターネットに接続しませんが、標準の Java ソケットを使用して Wi-Fi P2P ピアと通信するにはインターネット権限が必要です）。

また、Android システムは、特定の Wi-Fi P2P イベント中にさまざまなアクションをブロードキャストします。

詳細については、WifiP2pManager のドキュメントをご覧ください。サンプルアプリ Wi-Fi P2P Demo もご覧ください。

Bluetooth Health デバイス

Android で Bluetooth ヘルス プロファイル デバイスがサポートされるようになりました。これにより、Bluetooth を使用して Bluetooth をサポートするヘルスデバイス（心拍数モニター、血液計、体温計、体重計など）と通信するアプリを作成できます。

通常のヘッドセットや A2DP プロファイル デバイスと同様に、BluetoothProfile.ServiceListener と HEALTH プロファイル タイプを指定して getProfileProxy() を呼び出し、プロファイル プロキシ オブジェクトとの接続を確立する必要があります。

ヘルス プロファイル プロキシ（BluetoothHealth オブジェクト）を取得すると、ペア設定されたヘルスデバイスに接続して通信するには、次の新しい Bluetooth クラスが含まれます。

  • BluetoothHealthCallback: このクラスを拡張し、アプリの登録状態と Bluetooth チャネル状態の変化に関する最新情報を受け取るコールバック メソッドを実装する必要があります。
  • BluetoothHealthAppConfiguration: BluetoothHealthCallback へのコールバック中に、このオブジェクトのインスタンスを受け取ります。このオブジェクトは、利用可能な Bluetooth ヘルスデバイスに関する構成情報を提供します。BluetoothHealth API との接続の開始や終了など、さまざまなオペレーションを実行する際にこれを使用する必要があります。

Bluetooth ヘルス プロファイルの使用方法については、BluetoothHealth のドキュメントをご覧ください。

ユーザー補助

Android 4.0 では、新しいタッチガイドモードと拡張 API により、目の不自由なユーザー向けのユーザー補助機能が強化され、コンテンツ表示に関する詳細情報の提供や、高度なユーザー補助サービスの開発が可能になりました。

タッチガイドモード

視力喪失のあるユーザーは、画面を指でタッチしてドラッグし、コンテンツの音声による説明を聞くことで画面を探索できるようになりました。タッチガイドモードは仮想カーソルのように動作するため、スクリーン リーダーは、ユーザーが D-pad やトラックボールで移動するときと同じように、シミュレートされた「マウスオーバー」イベントで android:contentDescription と setContentDescription() から提供される情報を読み上げることで、説明テキストを特定できます。したがって、これは、アプリのビュー（特に ImageButton、EditText、ImageView など、自然に説明テキストが含まれない可能性があるウィジェット）には説明テキストを指定する必要があることに留意してください。

ビューのユーザー補助機能

スクリーン リーダーなどのユーザー補助サービスで利用できる情報を強化するには、カスタムの View コンポーネントにユーザー補助イベント用の新しいコールバック メソッドを実装します。

まず、Android 4.0 では sendAccessibilityEvent() メソッドの動作が変更されています。以前のバージョンの Android と同様に、ユーザーがデバイスでユーザー補助サービスを有効にして、クリックやカーソルを合わせるなどの入力イベントが発生すると、sendAccessibilityEvent() の呼び出しでそれぞれのビューに通知されます。これまでは、sendAccessibilityEvent() の実装により AccessibilityEvent が初期化され、AccessibilityManager に送信されていました。新しい動作には、ビューとその親がイベントにコンテキスト情報を追加できるようにする追加のコールバック メソッドが含まれます。

  1. 呼び出された場合、sendAccessibilityEvent() メソッドと sendAccessibilityEventUnchecked() メソッドは onInitializeAccessibilityEvent() に従います。

    View のカスタム実装では、onInitializeAccessibilityEvent() を実装して AccessibilityEvent に追加のユーザー補助情報を追加できますが、スーパー実装を呼び出して標準のコンテンツの説明やアイテム インデックスなどのデフォルト情報を提供する必要もあります。ただし、このコールバックにはテキスト コンテンツを追加しないでください。これは次に発生します。

  2. 初期化後、イベントがテキスト情報の入力が必要なタイプのいずれかである場合、ビューは dispatchPopulateAccessibilityEvent() の呼び出しを受け取ります。これは onPopulateAccessibilityEvent() コールバックに従います。

    View のカスタム実装では通常、android:contentDescription テキストがない場合や不十分な場合に、AccessibilityEvent にテキスト コンテンツを追加するために onPopulateAccessibilityEvent() を実装する必要があります。AccessibilityEvent に説明テキストを追加するには、getText().add() を呼び出します。

  3. この時点で View は、親ビューに対して requestSendAccessibilityEvent() を呼び出して、ビュー階層にイベントを渡します。各親ビューは、最終的にルートビューに到達するまで AccessibilityRecord を追加してユーザー補助情報を拡張できます。ルートビューは sendAccessibilityEvent() を使用してイベントを AccessibilityManager に送信します。

View クラスの拡張に便利な上記の新しいメソッドに加えて、AccessibilityDelegate を拡張して setAccessibilityDelegate() でビューに設定することで、任意の View でこれらのイベント コールバックをインターセプトすることもできます。その場合、ビュー内の各ユーザー補助メソッドで、デリゲート内の対応するメソッドへの呼び出しを延期します。たとえば、ビューは onPopulateAccessibilityEvent() への呼び出しを受け取ると、View.AccessibilityDelegate の同じメソッドに渡します。デリゲートで処理されないメソッドは、デフォルトの動作でビューに直接返されます。これにより、View クラスを拡張することなく、特定のビューに必要なメソッドのみをオーバーライドできます。

4.0 より前の Android バージョンとの互換性を維持しながら、新しいユーザー補助 API をサポートする場合は、下位互換性のある設計で新しいユーザー補助 API を提供するユーティリティ クラスのセットを使用して、最新バージョンの v4 サポート ライブラリ（互換性パッケージ、r4 内）を使用します。

ユーザー補助サービス

ユーザー補助サービスを開発している場合、さまざまなユーザー補助イベントに関する情報が大幅に拡張され、ユーザーがより高度なユーザー補助のフィードバックを行えるようになりました。特に、ビューの構成に基づいてイベントが生成され、より適切なコンテキスト情報が提供されます。これにより、ユーザー補助サービスはビュー階層を走査して追加のビュー情報を取得し、特殊なケースに対処できるようになります。

ユーザー補助サービス（スクリーン リーダーなど）を開発する場合は、次の手順で追加のコンテンツ情報にアクセスし、ビュー階層を走査できます。

  1. アプリから AccessibilityEvent を受け取ったら、AccessibilityEvent.getRecord() を呼び出して特定の AccessibilityRecord を取得します（イベントに複数のレコードが関連付けられている場合があります）。
  2. AccessibilityEvent または個々の AccessibilityRecord から、getSource() を呼び出して AccessibilityNodeInfo オブジェクトを取得できます。

    AccessibilityNodeInfo は、ウィンドウ コンテンツの単一ノードを、そのノードのユーザー補助情報をクエリできる形式で表します。AccessibilityEvent から返される AccessibilityNodeInfo オブジェクトはイベントソースを表しますが、AccessibilityRecord からのソースはイベントソースの前身を表します。

  3. AccessibilityNodeInfo を使用すると、その情報をクエリしたり、getParent() または getChild() を呼び出してビュー階層を走査したり、ノードに子ビューを追加したりできます。

アプリがユーザー補助サービスとしてシステムに公開されるようにするには、AccessibilityServiceInfo に対応する XML 構成ファイルを宣言する必要があります。ユーザー補助サービスの作成について詳しくは、AccessibilityService と SERVICE_META_DATA で XML 構成の説明をご覧ください。

その他のユーザー補助 API

デバイスのユーザー補助の状態に関心がある場合は、AccessibilityManager に次のような新しい API が追加されました。

スペルチェック サービス

新しいスペル チェッカー フレームワークでは、インプット メソッド フレームワーク（IME 用）と同様の方法で、アプリでスペル チェッカーを作成できます。新しいスペル チェッカーを作成するには、SpellCheckerService を拡張し、SpellCheckerService.Session クラスを拡張して、インターフェースのコールバック メソッドから提供されるテキストに基づいてスペル候補を提供するサービスを実装する必要があります。SpellCheckerService.Session コールバック メソッドでは、スペル候補を SuggestionsInfo オブジェクトとして返す必要があります。

スペル チェッカー サービスを使用するアプリは、そのサービスで必要とされる BIND_TEXT_SERVICE 権限を宣言する必要があります。また、インテントのアクションとして <action android:name="android.service.textservice.SpellCheckerService" /> を指定してインテント フィルタを宣言し、スペルチェックの設定情報を宣言する <meta-data> 要素を含める必要があります。

サンプルコードについては、 スペルチェック サービス アプリと スペルチェック クライアント アプリのサンプルをご覧ください。

テキスト読み上げエンジン

Android のテキスト読み上げ（TTS）API は大幅に拡張され、アプリでカスタム TTS エンジンをより簡単に実装できるようになりました。また、TTS エンジンを使用するアプリには、エンジンを選択するための新しい API がいくつか用意されています。

テキスト読み上げエンジンの使用

以前のバージョンの Android では、TextToSpeech クラスを使用して、システムが提供する TTS エンジンでテキスト読み上げ（TTS）オペレーションを実行するか、setEngineByPackageName() を使用してカスタム エンジンを設定できました。Android 4.0 では、setEngineByPackageName() メソッドのサポートが終了し、TTS エンジンのパッケージ名を受け入れる新しい TextToSpeech コンストラクタを使用して、使用するエンジンを指定できるようになりました。

getEngines() を使用して、使用可能な TTS エンジンをクエリすることもできます。このメソッドは、エンジンのアイコン、ラベル、パッケージ名などのメタデータを含む TextToSpeech.EngineInfo オブジェクトのリストを返します。

テキスト読み上げエンジンの構築

これまで、カスタム エンジンでは、ドキュメントに記載されていないネイティブ ヘッダー ファイルを使用してエンジンを構築する必要がありました。Android 4.0 には、TTS エンジンを構築するための一連のフレームワーク API が用意されています。

基本設定には、INTENT_ACTION_TTS_SERVICE インテントに応答する TextToSpeechService の実装が必要です。TTS エンジンの主な処理は、TextToSpeechService を拡張するサービスの onSynthesizeText() コールバック中に行われます。このメソッドには、次の 2 つのオブジェクトがあります。

  • SynthesisRequest: 合成するテキスト、言語 / 地域、音声の速度、音声のピッチなどのさまざまなデータが含まれます。
  • SynthesisCallback: TTS エンジンが生成された音声データをストリーミング オーディオとして配信する際のインターフェースです。まず、エンジンは start() を呼び出して、エンジンが音声を配信する準備ができていることを示す必要があります。次に、audioAvailable() を呼び出して、音声データをバイト バッファに渡す必要があります。エンジンがすべての音声をバッファに通したら、done() を呼び出します。

TTS エンジンを作成するための真の API がフレームワークでサポートされるようになったため、ネイティブ コード実装のサポートは削除されました。古い TTS エンジンを新しいフレームワークに変換するために使用できる互換性レイヤに関するブログ投稿を探します。

新しい API を使用した TTS エンジンの例については、Text To Speech Engine サンプルアプリをご覧ください。

ネットワーク使用状況

Android 4.0 では、アプリによるネットワーク データの使用量が正確に把握できます。設定アプリには、ネットワーク データ使用量の上限設定を管理したり、個々のアプリのバックグラウンド データの使用を無効にしたりできるコントロールが用意されています。ユーザーがバックグラウンドからデータへのアプリのアクセスを無効にしてしまうのを防ぐために、データ接続を効率的に使用する戦略を策定し、利用可能な接続の種類に応じて使用量を調整する必要があります。

アプリが大量のネットワーク トランザクションを実行する場合は、データの同期頻度、Wi-Fi 接続時のみアップロードやダウンロードを行うかどうか、ローミング時にのみデータを使用するかどうかなど、アプリのデータ習慣をユーザーが制御できるユーザー設定を提供する必要があります。こうした制御を利用できるようにすることで、データ使用の厳密な制限に近づいたときに、アプリのデータアクセスを無効にする可能性が大幅に低くなります。これらの設定で設定アクティビティを指定する場合は、マニフェストの宣言に ACTION_MANAGE_NETWORK_USAGE アクションのインテント フィルタを含める必要があります。次に例を示します。

<activity android:name="DataPreferences" android:label="@string/title_preferences">
    <intent-filter>
       <action android:name="android.intent.action.MANAGE_NETWORK_USAGE" />
       <category android:name="android.intent.category.DEFAULT" />
    </intent-filter>
</activity>

このインテント フィルタは、アプリのデータ使用量を管理するアクティビティであることをシステムに示します。そのため、ユーザーが設定アプリでアプリのデータ使用量を調べると、[アプリの設定を表示] ボタンを使って設定アクティビティを起動し、アプリのデータ使用量を調整できます。

また、getBackgroundDataSetting() は非推奨になり、常に true を返します。代わりに getActiveNetworkInfo() を使用してください。ネットワーク トランザクションを試す前に、必ず getActiveNetworkInfo() を呼び出して現在のネットワークを表す NetworkInfo を取得し、isConnected() に対してクエリを実行してデバイスが接続されているかどうかを確認する必要があります。これにより、デバイスがローミング中か、Wi-Fi に接続中かなど、他の接続プロパティを確認できます。

エンタープライズ

Android 4.0 では、エンタープライズ アプリの機能が次の機能によって拡張されています。

VPN サービス

新しい VpnService を使用すると、アプリは Service として実行される独自の VPN（バーチャル プライベート ネットワーク）を構築できます。VPN サービスは、独自のアドレスとルーティング ルールを持つ仮想ネットワークのインターフェースを作成し、ファイル記述子を使用してすべての読み取りと書き込みを実行します。

VPN サービスを作成するには、VpnService.Builder を使用して、ネットワーク アドレス、DNS サーバー、ネットワーク ルートなどを指定します。完了したら、ParcelFileDescriptor を返す establish() を呼び出してインターフェースを確立できます。

VPN サービスはパケットをインターセプトできるため、セキュリティ上の影響があります。そのため、VpnService を実装する場合、システムのみがバインドできるように、サービスで BIND_VPN_SERVICE を要求する必要があります（この権限はシステムにのみ付与され、アプリはリクエストできません）。VPN サービスを使用するには、ユーザーがシステム設定で手動で有効にする必要があります。

デバイス ポリシー

デバイス制限を管理するアプリでは、setCameraDisabled() と USES_POLICY_DISABLE_CAMERA プロパティ（ポリシー構成ファイルの <disable-camera /> 要素で適用）を使用してカメラを無効にできるようになりました。

証明書の管理

新しい KeyChain クラスには、システム キーストア内の証明書のインポートとアクセスを可能にする API が用意されています。証明書を使用すると、クライアント証明書（ユーザーの ID を検証するため）と認証局の証明書（サーバーの ID を確認するため）の両方を簡単にインストールできます。ウェブブラウザやメール クライアントなどのアプリケーションは、インストールされた証明書にアクセスして、サーバーに対してユーザーを認証できます。詳しくは、KeyChain のドキュメントをご覧ください。

デバイス センサー

Android 4.0 では、2 つの新しいセンサータイプが追加されました。

デバイスに TYPE_AMBIENT_TEMPERATURE センサーと TYPE_RELATIVE_HUMIDITY センサーの両方が搭載されている場合は、これらのセンサーを使用して露点温度と絶対湿度を計算できます。

以前の温度センサー TYPE_TEMPERATURE のサポートは終了しました。代わりに TYPE_AMBIENT_TEMPERATURE センサーを使用してください。

さらに、Android の 3 つの合成センサーが大幅に改善され、レイテンシが短縮され、出力がより滑らかになりました。これらのセンサーには、重力センサー（TYPE_GRAVITY）、回転ベクトル センサー（TYPE_ROTATION_VECTOR）、直線加速度センサー（TYPE_LINEAR_ACCELERATION）があります。改良されたセンサーは、ジャイロスコープ センサーを使用して出力を改善するため、センサーはジャイロスコープを備えたデバイスにのみ表示されます。

アクションバー

いくつかの新しい動作をサポートするように ActionBar が更新されました。最も重要な点は、あらゆる画面サイズで最適なユーザー エクスペリエンスを提供するため、小さい画面で実行される場合は、システムがアクションバーのサイズと設定を適切に管理することです。たとえば、画面が狭い場合（ハンドセットが縦向きなど）、アクションバーのナビゲーション タブはメインのアクションバーのすぐ下に表示される「積み重ねバー」に表示されます。「分割アクションバー」を有効にすることもできます。分割アクションバーを使用すると、画面が狭いときに、画面の下部にある別のバーにすべてのアクション アイテムが表示されます。

分割アクションバー

アクションバーに複数のアクション アイテムが含まれている場合、狭い画面ではすべてのアクション アイテムがアクションバーに収まらないため、システムによってオーバーフロー メニュー内に多くのアクション アイテムが配置されます。ただし、Android 4.0 では「分割アクションバー」を有効にして、画面下部にある別のバーにより多くのアクション アイテムを表示できます。分割アクションバーを有効にするには、マニフェスト ファイルの <application> タグまたは個々の <activity> タグに、"splitActionBarWhenNarrow" を指定した android:uiOptions を追加します。有効にすると、画面の幅が狭いときに、すべてのアクション アイテム用のバーが画面の下部に追加されます（プライマリ アクションバーにはアクション アイテムは表示されません）。

ActionBar.Tab API によって提供されるナビゲーション タブを使用するものの、上部にメイン アクションバーを必要としない場合（タブのみを上部に表示する場合は）、上記のように分割アクションバーを有効にし、setDisplayShowHomeEnabled(false) を呼び出してアクションバーのアプリアイコンを無効にします。メインのアクションバーには何も残っていないため消えます。残っているのは、画面上部のナビゲーション タブと下部のアクション アイテムだけです。

アクションバーのスタイル

アクションバーにカスタム スタイルを適用する場合は、新しいスタイル プロパティ backgroundStacked と backgroundSplit を使用して、背景ドローアブルまたは色を積み上げ棒と分割バーにそれぞれ適用できます。これらのスタイルは、実行時に setStackedBackgroundDrawable() と setSplitBackgroundDrawable() を使用して設定することもできます。

アクション プロバイダ

新しい ActionProvider クラスを使用すると、アクション アイテム専用のハンドラを作成できます。アクション プロバイダは、関連付けられている各アクション アイテムのアクション ビュー、デフォルトのアクション動作、サブメニューを定義できます。動的な動作を持つアクション アイテム（可変のアクション ビュー、デフォルトのアクション、サブメニューなど）を作成する場合は、フラグメントやアクティビティ内でさまざまなアクション アイテムの変換を処理するよりも、ActionProvider を拡張して再利用可能なコンポーネントを作成することをおすすめします。

たとえば、ShareActionProvider は ActionProvider の拡張機能で、アクションバーからの「共有」アクションを容易にします。ACTION_SEND インテントを呼び出す従来のアクション アイテムを使用する代わりに、このアクション プロバイダを使用すると、ACTION_SEND インテントを処理するアプリのプルダウン リストを含むアクション ビューを表示できます。ユーザーがアクションに使用するアプリを選択すると、ShareActionProvider はその選択を記憶してアクション ビューに表示し、そのアプリとの共有にすばやくアクセスできるようにします。

アクション アイテムのアクション プロバイダを宣言するには、アクティビティのオプション メニューの <item> 要素に android:actionProviderClass 属性を追加し、アクション プロバイダのクラス名を値として指定します。次に例を示します。

<item android:id="@+id/menu_share"
      android:title="Share"
      android:showAsAction="ifRoom"
      android:actionProviderClass="android.widget.ShareActionProvider" />

アクティビティの onCreateOptionsMenu() コールバック メソッドで、メニュー項目からアクション プロバイダのインスタンスを取得し、インテントを設定します。

Kotlin

override fun onCreateOptionsMenu(menu: Menu): Boolean {
    menuInflater.inflate(R.menu.options, menu)
    val shareActionProvider = menu.findItem(R.id.menu_share)?.actionProvider as? ShareActionProvider
    // Set the share intent of the share action provider.
    shareActionProvider?.setShareIntent(createShareIntent())
    ...
    return super.onCreateOptionsMenu(menu)
}

Java

public boolean onCreateOptionsMenu(Menu menu) {
    getMenuInflater().inflate(R.menu.options, menu);
    ShareActionProvider shareActionProvider =
          (ShareActionProvider) menu.findItem(R.id.menu_share).getActionProvider();
    // Set the share intent of the share action provider.
    shareActionProvider.setShareIntent(createShareIntent());
    ...
    return super.onCreateOptionsMenu(menu);
}

ShareActionProvider を使用する例については、ApiDemos の ActionBarShareActionProviderActivity をご覧ください。

折りたたみ可能な操作ビュー

アクション ビューを提供するアクション アイテムで、アクション ビューの状態と従来のアクション アイテムの状態を切り替えられるようになりました。これまでは、アクション ビューとして使用した場合の折りたたみは SearchView でのみサポートされていましたが、アクション アイテムにアクション ビューを追加して、展開状態（アクション ビューが表示可能）と折りたたみ状態（アクション アイテムは表示可能）を切り替えることができるようになりました。

アクション ビューを含むアクション アイテムが折りたたみ可能であることを宣言するには、メニューの XML ファイルで、<item> 要素の android:showAsAction 属性に “collapseActionView" フラグを含めます。

アクション ビューが展開状態と折りたたみ状態を切り替えたときにコールバックを受信するには、setOnActionExpandListener() を呼び出して、MenuItem.OnActionExpandListener のインスタンスをそれぞれの MenuItem に登録します。通常は、onCreateOptionsMenu() コールバック中に行う必要があります。

折りたたみ可能なアクション ビューを制御するには、それぞれの MenuItem で collapseActionView() と expandActionView() を呼び出します。

カスタム アクション ビューを作成するときに、新しい CollapsibleActionView インターフェースを実装して、ビューの展開時と折りたたみ時にコールバックを受け取ることもできます。

アクションバー用のその他の API

  • setHomeButtonEnabled() を使用すると、アイコンやロゴをホームに移動するボタンとして動作させるか、「上方」に移動するボタンとして動作させるかを指定できます（「true」を渡すとボタンとして動作できます）。
  • setIcon() と setLogo() を使用すると、実行時にアクションバーのアイコンまたはロゴを定義できます。
  • Fragment.setMenuVisibility() を使用すると、フラグメントによって宣言されたオプション メニュー項目の表示を有効または無効にできます。これは、フラグメントがアクティビティに追加されているものの、表示されていないためメニュー項目を非表示にする必要がある場合に便利です。
  • FragmentManager.invalidateOptionsMenu() を使用すると、フラグメントのライフサイクルのさまざまな状態（Activity の同等のメソッドを使用できない可能性がある）で、アクティビティ オプション メニューを無効にできます。

ユーザー インターフェースと表示

Android 4.0 では、さまざまな新しいビューやその他の UI コンポーネントが導入されています。

GridLayout

GridLayout は、子ビューを長方形のグリッド内に配置する新しいビューグループです。TableLayout とは異なり、GridLayout はフラットな階層に依存しており、構造を提供するためにテーブル行などの中間ビューを使用しません。代わりに、子は占有する行と列を指定します（セルは複数の行や列にまたがることができます）。デフォルトでは、グリッドの行と列にわたって順番に配置されます。GridLayout の向きによって、連続する子をデフォルトで水平方向と垂直方向のどちらに配置するかが決まります。子間のスペースを指定するには、新しい Space ビューのインスタンスを使用するか、子に関連するマージン パラメータを設定します。

GridLayout を使用するサンプルについては、ApiDemos をご覧ください。

TextureView

TextureView は、動画や OpenGL シーンなどのコンテンツ ストリームを表示できる新しいビューです。SurfaceView と似ていますが、TextureView は別のウィンドウを作成するのではなく、通常のビューのように動作する点で他の View オブジェクトと同様に扱うことができます。たとえば、変換を適用したり、ViewPropertyAnimator を使用してアニメーション化したり、setAlpha() を使用して不透明度を調整したりできます。

TextureView は、ハードウェア アクセラレーションされているウィンドウ内でのみ動作します。

詳細については、TextureView のドキュメントをご覧ください。

ウィジェットを切り替える

新しい Switch ウィジェットは 2 つの状態の切り替えで、ユーザーは片側にドラッグ（または単にタップ）して、2 つの状態の間でオプションを切り替えることができます。

android:textOn 属性と android:textOff 属性を使用して、オン / オフの設定でスイッチに表示するテキストを指定できます。android:text 属性を使用すると、スイッチの横にラベルを配置することもできます。

スイッチを使用する例については、switches.xml レイアウト ファイルと、それぞれの Switches のアクティビティをご覧ください。

Android 3.0 で導入された PopupMenu を使用すると、指定したアンカー ポイント（通常はアイテムの選択ポイント）にポップアップする短いコンテキスト メニューを作成できます。Android 4.0 では、PopupMenu が拡張され、次のような便利な機能が追加されています。

  • XML メニュー リソースから、ポップアップ メニューのコンテンツを inflate() で簡単にインフレートして、メニュー リソース ID を渡すことができるようになりました。
  • また、メニューが閉じられたときにコールバックを受け取る PopupMenu.OnDismissListener を作成できるようになりました。

設定

新しい TwoStatePreference 抽象クラスは、2 つの状態の選択オプションを提供する設定の基礎となります。新しい SwitchPreference は TwoStatePreference の拡張機能であり、設定ビューに Switch ウィジェットを提供します。これにより、ユーザーは追加の設定画面やダイアログを開かずに設定のオンとオフを切り替えることができます。たとえば、設定アプリは Wi-Fi 設定と Bluetooth 設定に SwitchPreference を使用します。

システムテーマ

Android 4.0 をターゲットとするすべてのアプリのデフォルトのテーマ（targetSdkVersion または minSdkVersion を “14" 以上に設定）は、「デバイスのデフォルト」テーマの Theme.DeviceDefault になりました。これはダークホロテーマの場合もあれば、特定のデバイスで定義されている別のダークテーマである場合もあります。

同じバージョンの Android を実行している場合、Theme.Holo テーマのテーマはデバイス間で変更されないことが保証されています。アクティビティに Theme.Holo テーマを明示的に適用した場合、これらのテーマは同じプラットフォーム バージョン内の異なるデバイスでも文字が変更されません。

アプリをデバイスのテーマ全体に溶け込ませる場合（異なる OEM がシステムに異なるデフォルトのテーマを提供する場合など）は、Theme.DeviceDefault ファミリーのテーマを明示的に適用する必要があります。

オプション メニューボタン

Android 4.0 以降、ハンドセットではメニュー ハードウェア ボタンが不要になりました。ただし、既存のアプリにオプション メニューがあり、メニューボタンがあることを想定している場合は、このことを心配する必要はありません。既存のアプリが引き続き想定どおりに動作するように、古いバージョンの Android 向けに設計されたアプリには、画面上にメニューボタンが表示されます。

最適なユーザー エクスペリエンスを実現するには、新規および更新されたアプリでは、代わりに ActionBar を使用してメニュー項目へのアクセスを提供し、targetSdkVersion を "14" に設定して最新のフレームワークのデフォルト動作を活用する必要があります。

システム UI 表示のコントロール

Android の初期から、システムは「ステータスバー」と呼ばれる UI コンポーネントを管理してきました。ステータスバーは、ハンドセット デバイスの上部にあり、携帯通信会社の電波、時刻、通知などの情報を配信します。Android 3.0 では、タブレット デバイス用のシステムバーが追加されました。これは画面の下部に配置され、システム ナビゲーション コントロール（ホーム、戻るなど）と、これまでステータスバーで提供されていた要素のインターフェースを提供します。Android 4.0 では、ナビゲーション バーという新しいタイプのシステム UI が用意されています。ナビゲーション バーは、ハンドセット用に設計されたシステムバーを再調整したものと考えることができます。ナビゲーション バーは、システムを操作するハードウェアのないデバイスにもナビゲーション コントロールを提供しますが、システムバーの通知 UI と設定コントロールは提供しません。そのため、ナビゲーション バーを備えたデバイスには、上部にステータスバーもあります。

これまでは、FLAG_FULLSCREEN フラグを使用してハンドセットのステータスバーを非表示にできます。Android 4.0 では、システムバーの表示を制御する API が更新され、システムバーとナビゲーション バーの両方の動作をより正確に反映しています。

  • SYSTEM_UI_FLAG_LOW_PROFILE フラグは STATUS_BAR_HIDDEN フラグに代わるものです。このフラグを設定すると、システムバーまたはナビゲーション バーで「ロー プロファイル」モードが有効になります。ナビゲーション ボタンが暗くなり、システムバーの他の要素も非表示になります。これを有効にすると、システム ナビゲーション ボタンの邪魔にならないように没入感の高いゲームを作成できます。
  • システムバーまたはナビゲーション バーを表示する場合は、STATUS_BAR_VISIBLE フラグの代わりに SYSTEM_UI_FLAG_VISIBLE フラグを使用します。
  • SYSTEM_UI_FLAG_HIDE_NAVIGATION は、ナビゲーション バーを完全に非表示にすることをリクエストする新しいフラグです。ただし、この機能は一部のスマートフォンで使用されるナビゲーション バーでのみ機能します（タブレットではシステムバーは非表示になりません）。システムがユーザー入力を受け取るとすぐに、ナビゲーション バーは表示に戻ります。そのため、このモードは主に動画の再生など、画面全体は必要だがユーザー入力は不要な場合に役立ちます。

アクティビティ内の任意のビューで setSystemUiVisibility() を呼び出すことで、システムバーとナビゲーション バーにこれらの各フラグを設定できます。ウィンドウ マネージャーは、ウィンドウ内のすべてのビューからのすべてのフラグを結合（または OR）して結合し、ウィンドウに入力フォーカスがある限り、システム UI に適用します。ウィンドウが入力フォーカスを失った場合（ユーザーがアプリから離れるか、ダイアログが表示される）、フラグは無効になります。同様に、これらのビューをビュー階層から削除すると、フラグは適用されなくなります。

アクティビティ内の他のイベントをシステム UI の公開設定の変更と同期させる（たとえば、システム UI が非表示のときにアクションバーやその他の UI コントロールを非表示にする）には、View.OnSystemUiVisibilityChangeListener を登録して、システムバーまたはナビゲーション バーの可視性が変更されたときに通知されるようにする必要があります。

さまざまなシステム UI オプションのデモについては、 OverscanActivity クラスをご覧ください。

入力フレームワーク

Android 4.0 では、カーソルのホバーイベントと、新しいタッチペンおよびマウスボタン イベントのサポートが追加されています。

マウスオーバー イベント

View クラスが「カーソルを合わせる」イベントをサポートするようになり、ポインタ デバイス（マウスや、画面上のカーソルを動かすその他のデバイスなど）を使用したリッチな操作が可能になりました。

ビューでホバー イベントを受信するには、View.OnHoverListener を実装して setOnHoverListener() に登録します。ビューでホバーイベントが発生すると、リスナーは onHover() の呼び出しを受け取り、イベントを受け取った View と、発生したホバーイベントの種類を示す MotionEvent を渡します。マウスオーバー イベントは、次のいずれかになります。

View.OnHoverListener がホバーイベントを処理する場合、onHover() から true を返す必要があります。リスナーから false が返された場合、通常どおりホバーイベントが親ビューにディスパッチされます。

現在の状態に基づいて外観が変化するボタンやその他のウィジェットをアプリで使用する場合、状態リスト ドローアブルで android:state_hovered 属性を使用して、ビューにカーソルを合わせたときに別の背景ドローアブルを提供できるようになりました。

新しいホバー イベントのデモについては、ApiDemos の Hover クラスをご覧ください。

タッチペンとマウスボタンのイベント

Android では、デジタイザー タブレットの周辺機器やタッチペン対応のタッチ スクリーンなど、タッチペン入力デバイスから入力を受信するための API が提供されるようになりました。

タッチペン入力は、タップ入力やマウス入力と同様に動作します。タッチペンがデジタイザーに接触すると、アプリはディスプレイを指でタッチするときと同様にタッチイベントを受け取ります。タッチペンがデジタイザーの上でホバーすると、ボタンが押されていない状態でマウスポインタがディスプレイ上を移動したときと同様に、アプリはホバー イベントを受け取ります。

アプリでは、getToolType() を使用して MotionEvent 内の各ポインタに関連付けられている「ツールタイプ」を照会することで、指、マウス、タッチペン、消しゴムによる入力を区別できます。現在定義されているツールタイプは、TOOL_TYPE_UNKNOWN、TOOL_TYPE_FINGER、TOOL_TYPE_MOUSE、TOOL_TYPE_STYLUS、TOOL_TYPE_ERASER です。アプリはツールタイプをクエリすることで、指やマウスの入力とは異なる方法でタッチペン入力を処理できます。

アプリは、どのマウスボタンまたはタッチペン ボタンが押されているかを照会することもできます。そのためには、getButtonState() を使用して MotionEvent の「ボタン状態」を照会します。現在定義されているボタンの状態は、BUTTON_PRIMARY、BUTTON_SECONDARY、BUTTON_TERTIARY、BUTTON_BACK、BUTTON_FORWARD です。便宜上、マウスの戻るボタンと進むボタンは自動的に KEYCODE_BACK キーと KEYCODE_FORWARD キーにマッピングされます。アプリはこれらのキーを処理して、マウスボタンに基づく「戻る」と「進む」ナビゲーションをサポートできます。

一部のタッチペン入力デバイスでは、接触の位置と圧力を正確に測定できるほか、タッチペンの先端とデジタイザーの距離、タッチペンの傾斜角度、タッチペンの向き角度も報告されます。アプリケーションは、軸コード AXIS_DISTANCE、AXIS_TILT、AXIS_ORIENTATION を指定した getAxisValue() を使用して、この情報のクエリを実行できます。

ツールタイプ、ボタンの状態、新しい軸コードのデモについては、ApiDemos の TouchPaint クラスをご覧ください。

プロパティ

新しい Property クラスを使用すると、任意のオブジェクトのプロパティを迅速、効率的、かつ簡単に指定でき、呼び出し元はターゲット オブジェクトに対して一般的な値の設定や取得を行うことができます。また、フィールドやメソッドの参照を渡す機能も可能になり、フィールドやメソッドの詳細を知らなくても、コードでプロパティの値を設定または取得できます。

たとえば、オブジェクト foo でフィールド bar の値を設定する場合は、次のように設定していました。

Kotlin

foo.bar = value

Java

foo.bar = value;

基になる非公開フィールド bar のセッターを呼び出す場合は、以前次のようにしていました。

Kotlin

foo.setBar(value)

Java

foo.setBar(value);

ただし、foo インスタンスを渡して、他のコードで bar 値を設定したい場合、Android 4.0 より前のバージョンではそのような方法はありません。

Property クラスを使用すると、クラス Foo で Property オブジェクト BAR を宣言し、次のようにクラス Foo のインスタンス foo のフィールドを設定できます。

Kotlin

BAR.set(foo, value)

Java

BAR.set(foo, value);

View クラスが Property クラスを利用して、Android 3.0 で追加された変換プロパティ（ROTATION、ROTATION_X、TRANSLATION_X など）などのさまざまなフィールドを設定できるようになりました。

また、ObjectAnimator クラスは Property クラスを使用するため、Property で ObjectAnimator を作成できます。これは、文字列ベースのアプローチよりも高速で、効率的、かつ型安全性の高い方法です。

ハードウェア アクセラレーション

Android 4.0 以降では、アプリで targetSdkVersion または minSdkVersion のいずれかを “14" 以上に設定した場合、すべてのウィンドウのハードウェア アクセラレーションがデフォルトで有効になります。一般に、ハードウェア アクセラレーションにより、アニメーションが滑らかになり、スクロールがスムーズになり、全体的なパフォーマンスとユーザー操作に対する応答が向上します。

必要に応じて、個々の <activity> 要素または <application> 要素の hardwareAccelerated 属性を使用して、ハードウェア アクセラレーションを手動で無効にできます。また、setLayerType(LAYER_TYPE_SOFTWARE) を呼び出すことで、個々のビューのハードウェア アクセラレーションを無効にすることもできます。

サポートされていない描画オペレーションのリストなど、ハードウェア アクセラレーションについて詳しくは、ハードウェア アクセラレーションのドキュメントをご覧ください。

JNI の変更

以前のバージョンの Android では、JNI ローカル参照は間接ハンドルではありませんでした。Android はダイレクト ポインタを使用していました。これは、ガベージ コレクタがオブジェクトを移動しない限り問題にはなりませんが、バグのあるコードを作成できるため、動作しているように見えました。Android 4.0 では、これらのバグを検出するために間接参照が使用されるようになりました。

JNI ローカル参照の詳細については、JNI のヒントの「ローカル参照とグローバル参照」をご覧ください。Android 4.0 では、これらのエラーを検出するように CheckJNI が強化されています。JNI 参照に関する一般的なエラーとその修正方法については、今後の投稿である Android デベロッパー ブログをご覧ください。

この JNI 実装の変更は、targetSdkVersion または minSdkVersion を “14" 以上に設定して、Android 4.0 をターゲットとするアプリにのみ影響します。これらの属性を小さい値に設定すると、JNI ローカル参照は以前のバージョンと同じように動作します。

Webkit

  • WebKit がバージョン 534.30 に更新されました
  • WebView と組み込みのブラウザでインド語フォント（デバナーガリ語、ベンガル語、タミル語、グリフを組み合わせるために必要な複雑な文字のサポートを含む）をサポート
  • WebView と組み込みブラウザでのエチオピック フォント、ジョージア フォント、アルメニア フォントのサポート
  • WebDriver のサポートにより、WebView を使用するアプリのテストが容易になります。

Android ブラウザ

ブラウザ アプリケーションには、ウェブ アプリケーションをサポートするために次の機能が追加されています。

権限

新しい権限は次のとおりです。

  • ADD_VOICEMAIL: ボイスメール サービスにボイスメール メッセージの追加を許可します。
  • BIND_TEXT_SERVICE: SpellCheckerService を実装するサービス自体にこの権限が必要になります。
  • BIND_VPN_SERVICE: VpnService を実装するサービス自体にこの権限が必要になります。
  • android.Manifest.permission#READ_PROFILE: ContactsContract.Profile プロバイダへの読み取りアクセス権を付与します。
  • android.Manifest.permission#WRITE_PROFILE: ContactsContract.Profile プロバイダに対する書き込みアクセス権を付与します。

デバイスの機能

デバイスの新機能は次のとおりです。

  • FEATURE_WIFI_DIRECT: アプリがピアツーピア通信に Wi-Fi を使用することを宣言します。

Android 4.0（API レベル 14）におけるすべての API の変更点について詳しくは、API 差分レポートをご覧ください。

以前の API

上記すべてに加えて、Android 4.0 では必然的に以前のリリースのすべての API がサポートされます。 Android 3.x プラットフォームは大画面デバイスでのみ利用できるため、主にハンドセット向けに開発している場合は、これらの最近のリリースで Android に追加されたすべての API を把握していない可能性があります。

ここでは、ハンドセットでも利用可能になった、見逃したかもしれない特に注目すべき API をいくつか紹介します。

Android 3.0
  • Fragment: アクティビティの個別の要素を、独自の UI とライフサイクルを定義する自己完結型のモジュールに分割できるフレームワーク コンポーネント。フラグメントのデベロッパー ガイドをご覧ください。
  • ActionBar: アクティビティ ウィンドウの上部にある従来のタイトルバーの代替機能。左上にはアプリケーションのロゴが表示され、メニュー項目の新しいインターフェースが提供されます。アクションバー デベロッパー ガイドをご覧ください。
  • Loader: UI コンポーネントと組み合わせてデータの非同期読み込みを行い、メインスレッドをブロックせずにデータを動的に読み込むフレームワーク コンポーネント。ローダのデベロッパー ガイドをご覧ください。
  • システム クリップボード: アプリはシステム全体のクリップボードとの間で、テキスト以外のデータをコピーして貼り付けることができます。クリップされたデータは、書式なしテキスト、URI、またはインテントです。コピーと貼り付けのデベロッパー ガイドをご覧ください。
  • ドラッグ&ドロップ: ドラッグ&ドロップ オペレーションを容易にする、ビュー フレームワークに組み込まれた API のセット。ドラッグ&ドロップに関するデベロッパー ガイドをご覧ください。
  • 柔軟性に優れたまったく新しいアニメーション フレームワークを使用すると、任意のオブジェクト（ビュー、ドローアブル、フラグメント、オブジェクトなど）の任意のプロパティをアニメーション化し、期間、補間、繰り返しなどのアニメーション要素を定義できます。新しいフレームワークにより、Android のアニメーションがこれまで以上にシンプルになります。プロパティ アニメーションのデベロッパー ガイドをご覧ください。
  • RenderScript グラフィックと Compute Engine: RenderScript は、ネイティブ レベルで高性能 3D グラフィック レンダリングとコンピューティング API を提供します。これは C（C99 標準）で記述します。これにより、さまざまな CPU と GPU 間で移植可能でありながら、ネイティブ環境から期待されるタイプのパフォーマンスを実現できます。詳しくは、RenderScript デベロッパー ガイドをご覧ください。
  • ハードウェア アクセラレーション 2D グラフィック: マニフェスト要素の <application> 要素または個々の <activity> 要素で {android:hardwareAccelerated="true"} を設定することで、アプリで OpenGL レンダラを有効にできるようになりました。これにより、アニメーションやスクロールがよりスムーズになり、パフォーマンスとユーザー操作に対する応答が全体的に向上します。

    注: アプリケーションの minSdkVersion または targetSdkVersion を "14" 以上に設定すると、ハードウェア アクセラレーションがデフォルトで有効になります。

  • その他多数詳しくは、Android 3.0 プラットフォームに関する注意事項をご覧ください。
Android 3.1
  • USB API: 接続されている周辺機器を Android アプリと統合するための強力な新しい API。API は、プラットフォームに組み込まれた USB スタックとサービスに基づいており、USB ホストとデバイスの両方のインタラクションをサポートします。USB ホストとアクセサリに関するデベロッパー ガイドをご覧ください。
  • MTP/PTP API: アプリは、接続されたカメラやその他の PTP デバイスと直接やり取りして、デバイスの取り付けや取り外しに関する通知の受信、デバイスのファイルとストレージの管理、デバイスとのファイルやメタデータの転送を行うことができます。MTP API は、MTP（メディア転送プロトコル）仕様の PTP（画像転送プロトコル）サブセットを実装します。詳しくは、android.mtp のドキュメントをご覧ください。
  • RTP API: Android は、組み込みの RTP（リアルタイム トランスポート プロトコル）スタックに API を公開しています。アプリケーションはこのスタックを使用して、オンデマンドまたはインタラクティブなデータ ストリーミングを管理できます。特に、VoIP、プッシュツートーク、会議、音声ストリーミングを提供するアプリでは、この API を使用してセッションを開始し、利用可能なネットワーク上でデータ ストリームを送受信できます。android.net.rtp のドキュメントをご覧ください。
  • ジョイスティックとその他の汎用モーション入力をサポート。
  • その他の新しい API については、Android 3.1 プラットフォームに関する注意事項をご覧ください。
Android 3.2
  • 新しい画面では、さまざまな画面サイズでアプリをどのように表示するかをより細かく制御できる API がサポートされています。この API は、既存の画面サポートモデルを拡張して、特定の画面サイズの範囲を、汎用の画面サイズ（large、xlarge など）ではなく、密度非依存のピクセル単位（幅 600 dp や 720 dp など）で測定した寸法に基づいて正確にターゲットにできます。たとえば、従来はどちらも「大」画面として分類されていた 5 インチのデバイスと 7 インチのデバイスを区別するうえで、これは重要です。ブログ投稿 画面サイズを管理する新しいツールをご覧ください。
  • <uses-feature> の新しい定数で、横向きまたは縦向きの画面方向の要件を宣言できるようになりました。
  • 画面の向きが変更されると、デバイスの「画面サイズ」構成も変更されるようになりました。API レベル 13 以降をターゲットとするアプリで "orientation" 構成の変更も処理する場合は、"screenSize" 構成の変更も処理する必要があります。詳しくは、android:configChanges をご覧ください。
  • 他の新しい API については、Android 3.2 プラットフォームに関する注意事項をご覧ください。

API レベル

Android 4.0 API には整数 ID（14）が割り当てられ、システム自体に格納されます。「API レベル」と呼ばれるこの識別子により、アプリをインストールする前に、アプリがシステムと互換性を正しく判断できるようになります。

Android 4.0 で導入された API をアプリで使用するには、API レベル 14 以上をサポートする Android プラットフォームに対してアプリをコンパイルする必要があります。必要に応じて、<uses-sdk> 要素に android:minSdkVersion="14" 属性を追加する必要もあります。

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