Android 4.0 API

API レベル: 14

Android 4.0(ICE_CREAM_SANDWICH)はプラットフォームのメジャー リリースで、ユーザーとアプリ デベロッパー向けにさまざまな新機能が追加されています。以下で説明するすべての新機能と API に加え、Android 4.0 は、Android 3.x の広範な API とホログラフィック テーマを小さな画面で利用できるため、重要なプラットフォーム リリースです。アプリ デベロッパーは単一のプラットフォームと統合 API フレームワークを使用でき、単一の APK でアプリを開発して公開できるようになりました。これにより、同じバージョンの Android(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 は、デバイス所有者の個人用プロファイルや、デバイスにインストールされているソーシャル ネットワークにユーザーが個々の連絡先を招待する機能など、新しいソーシャル向けの機能をサポートするように拡張されています。

ユーザー プロフィール

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

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

招待インテント

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

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

サイズの大きい写真

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

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

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

カレンダー プロバイダ

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

これらの API を使用すると、さまざまなアプリやウィジェットでカレンダーの予定の読み取りや変更を行うことができます。ただし、最も魅力的なユースケースのいくつかは、ユーザーのカレンダーを他のカレンダー サービスのカレンダー プロバイダと同期して、ユーザーのすべての予定に対して統合された場所を提供する同期アダプターです。たとえば、Google カレンダーの予定は、Google カレンダー同期アダプターによってカレンダー プロバイダと同期されるため、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 つの視覚的なプレゼンテーションで表示できるようになります。たとえば、ユーザーが複数のボイスメール ソース(スマートフォンのサービス プロバイダから 1 つと、VoIP または他の代替音声サービスからしたものなど)を使用している可能性があります。これらのアプリは、Voicemail Provider API を使用してボイスメールをデバイスに追加できます。その後、組み込みの電話アプリケーションによって、すべてのボイスメールが統合されたプレゼンテーションに表示されます。システムの電話アプリがすべてのボイスメールを読み取ることができる唯一のアプリケーションですが、ボイスメールを提供する各アプリは、システムに追加されたボイスメールを読み取ることができます(他のサービスのボイスメールを読み取ることはできません)。

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

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

マルチメディア

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

メディア エフェクト

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

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

  1. GL_TEXTURE_2D テクスチャ画像にバインドする必要がある
  2. mipmap レベルが 1 つ以上含まれている必要があります。

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

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

エフェクトのパラメータを調整するには、setParameter() を呼び出してパラメータ名とパラメータ値を渡します。エフェクトのタイプごとに、さまざまなパラメータを受け入れ、エフェクト名とともにドキュメント化されます。たとえば、EFFECT_FISHEYE には歪みの scale のパラメータが 1 つあります。

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

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

リモコン クライアント

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

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

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

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

再生中のメディアに関する情報をリモコンに表示するには、editMetaData() を呼び出して、返された RemoteControlClient.MetadataEditor にメタデータを追加します。メディア アートワーク、経過時間などの数値情報、トラック タイトルなどのテキスト情報用のビットマップを指定できます。使用可能なキーについては、MediaMetadataRetrieverMETADATA_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_PICTUREsetFocusMode() に渡します。写真を撮影する準備ができたら、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 ビームは、デバイス間で NDEF メッセージを送信できる新しい NFC 機能です(「NDEF プッシュ」とも呼ばれるプロセス)。データ転送は、Android ビームをサポートする 2 台の Android 搭載デバイスを近づけます(約 4 cm 以内)。通常は背面を近づけます。NDEF メッセージ内のデータには、デバイス間で共有する任意のデータを含めることができます。たとえば、連絡帳アプリは連絡先、YouTube は動画、ブラウザは Android ビームを使用して URL を共有します。

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

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

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

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

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

    この場合、アクティビティがフォアグラウンドにある間に別のデバイスで Android ビームが有効になると、システムは createNdefMessage() を呼び出して、送信したい NdefMessage を取得します。これにより、アクティビティの存続期間を通じてメッセージの内容が変化する場合に備えて、Android ビームが開始されたら 1 回だけ配信する 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 を起動し、アプリをインストールするためにユーザーをアプリに移動します。

アプリが NDEF プッシュ メッセージングを実行するために NFC API を使用しない場合、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 ヘルスデバイス

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

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

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

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

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

ユーザー補助

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

タッチガイドモード

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

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

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

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

  1. 呼び出されると、sendAccessibilityEvent() メソッドと sendAccessibilityEventUnchecked() メソッドには onInitializeAccessibilityEvent() が適用されます。

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

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

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

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

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

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

ユーザー補助サービス

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

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

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

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

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

アプリをユーザー補助サービスとしてシステムに公開するには、AccessibilityServiceInfo に対応する XML 構成ファイルを宣言する必要があります。ユーザー補助サービスの作成の詳細については、AccessibilityServiceSERVICE_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 が 2 つあります。

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

以前のバージョンの 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 では「分割アクションバー」を有効にして、画面の下部にある個別のバーに、より多くのアクション アイテムを表示できます。分割アクションバーを有効にするには、マニフェスト ファイルで android:uiOptions"splitActionBarWhenNarrow"<application> タグまたは個々の <activity> タグのいずれかに追加します。有効にすると、画面が狭いときは、すべてのアクション アイテム用のバーが画面の下部に追加されます(プライマリ アクション バーにはアクション アイテムは表示されません)。

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

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

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

アクション プロバイダ

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

たとえば、ShareActionProviderActionProvider の拡張機能であり、アクションバーからの「共有」アクションを容易にします。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() コールバック中に行う必要があります。

折りたたみ可能なアクション ビューを制御するには、それぞれの MenuItemcollapseActionView()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 シーンなどのコンテンツ ストリームを表示できる新しいビューです。TextureViewSurfaceView と似ていますが、別のウィンドウを作成するのではなく通常のビューと同じように動作し、他の 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 つの状態選択オプションを提供する設定のベースとして機能します。新しい SwitchPreferenceTwoStatePreference の拡張機能であり、設定ビューに Switch ウィジェットを提供します。これにより、ユーザーは追加の設定画面やダイアログを開くことなく、設定のオン / オフを切り替えることができます。たとえば、設定アプリは、Wi-Fi 設定と Bluetooth 設定に SwitchPreference を使用しています。

システムテーマ

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

Theme.Holo テーマ ファミリーは、同じバージョンの Android を実行しているときに、デバイス間で変更されないことが保証されています。アクティビティにいずれかの 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 クラスが「hover」イベントをサポートするようになりました。これにより、ポインタ デバイス(マウスや、画面上のカーソルを操作するその他のデバイス)を使用して、より充実した操作が可能になりました。

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

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

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

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

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

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

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

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

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

一部のタッチペン入力デバイスでは、接触の位置と圧力の正確な測定に加えて、タッチペンの先端とデジタイザーの距離、タッチペンの傾斜角度、タッチペンの向き角度も報告されます。アプリケーションは、軸コード AXIS_DISTANCEAXIS_TILTAXIS_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 クラスを使用して、クラス FooProperty オブジェクト BAR を宣言し、次のように、クラス Foo のインスタンス foo でフィールドを設定できます。

Kotlin

BAR.set(foo, value)

Java

BAR.set(foo, value);

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

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

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

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

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

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

JNI の変更

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

JNI ローカル参照の詳細については、JNI のヒントの「Local and Global References」をご覧ください。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 で、ドラッグ&ドロップ操作を容易にします。ドラッグ&ドロップに関するデベロッパー ガイドをご覧ください。
  • まったく新しい柔軟なアニメーション フレームワークを使用すると、任意のオブジェクト(View、Drawable、Fragment、Object など)の任意のプロパティをアニメーション化し、期間、補間、繰り返しなどのアニメーションの側面を定義できます。新しいフレームワークにより、Android のアニメーションがこれまで以上にシンプルになります。プロパティ アニメーションのデベロッパー ガイドをご覧ください。
  • RenderScript のグラフィックとコンピューティング エンジン: 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 は、既存の画面サポートモデルを拡張して、特定の画面サイズ範囲を、汎用の画面サイズ(大、特大など)ではなく、密度非依存のピクセル単位(幅 600 dp や 720 dp)で測定した寸法に基づいて、正確にターゲットを設定する機能を提供します。これは、従来はどちらも「大」画面としてバケット化されていた 5 インチのデバイスと 7 インチのデバイスを区別するために重要です。ブログ投稿の 画面サイズを管理するための新しいツールをご覧ください。
  • 横向きまたは縦向きの画面要件を宣言するための <uses-feature> の新しい定数。
  • 画面の向きを変更したときに、デバイスの「画面サイズ」構成が変更されるようになりました。API レベル 13 以降をターゲットとしているアプリで "orientation" 構成の変更も処理する場合は、"screenSize" 構成の変更を処理する必要があります。詳しくは、android:configChanges をご覧ください。
  • その他の新しい API については、Android 3.2 プラットフォームの注意事項をご覧ください。

API レベル

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

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

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