Android 4.0 API

API レベル: 14

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

開発者向けの Android 4.0 プラットフォームは、Android SDK のダウンロード可能なコンポーネントとして入手できます。このダウンロード可能なプラットフォームには 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 のテーブルにプロファイルの未加工連絡先を追加する必要があります。このテーブルの未加工のコンタクトは、ユーザーに表示される単一のプロフィール「自分」に集約されます。

プロファイルに新しい未加工連絡先を追加するには、 android.Manifest.permission#WRITE_PROFILE 権限が必要です。同様に、プロファイルから読み取るには android.Manifest.permission#READ_PROFILE 権限をリクエストする必要があります。ただし、 ほとんどのアプリは、ユーザー プロファイルの読み取りを不要にすべきです。たとえデータが 選択します。ユーザー プロフィールの読み取りは機密情報に関わる権限であり、ユーザーのプライバシーに配慮する必要があります。 要求するアプリに懐疑的です。

招待インテント

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

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

サイズの大きい写真

Android で、連絡先の高解像度写真がサポートされるようになりました。これで、写真を 連絡先レコードがあると、システムはそれを（以前と同じように）96x96 のサムネイルと 256x256 "表示写真"新しいファイルベースのフォトストア（ システムの選択は今後変わる可能性があります）。連絡先にサイズの大きい写真を追加するには、 通常の PHOTO 列に そのデータ行が適切なサムネイルと表示写真に変換されます。 記録します。

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

新しい ContactsContract.DataUsageFeedback API を使用すると、 ユーザーが特定の連絡手段を使用した頻度 取得しようと試みます。この情報は、各ユーザーに関連付けられている各連絡方法のランキングを改善し、各ユーザーへの連絡方法に関するより適切な候補を提案するために役立ちます。

カレンダー プロバイダ

新しい Calendar API を使用すると、カレンダー、予定、参加者、カレンダー、イベントの読み取り、追加、変更、削除が リマインダーとアラート（Calendar Provider に保存されているもの）

さまざまなアプリやウィジェットは、これらの API を使用してカレンダーの予定を読み取り、変更できます。ただし、 最も説得力のあるユースケースとして、ユーザーのカレンダーを Google Workspace から 他のカレンダー サービスをカレンダー プロバイダと連携させることで、すべてのカレンダー アプリケーションの できます。たとえば、Google カレンダーの予定は Google カレンダー同期アダプタによってカレンダー プロバイダと同期されるため、Android の組み込みカレンダー アプリでこれらの予定を表示できます。

カレンダー プロバイダでのカレンダーと予定関連情報のデータモデルは次のとおりです。 CalendarContract で定義されます。ユーザーのカレンダー データはすべて CalendarContract のさまざまなサブクラスで定義されたテーブルの数:

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

カレンダー プロバイダを使用してユーザーのカレンダー データにアクセスするには、アプリケーションで READ_CALENDAR 権限（読み取りアクセス用） WRITE_CALENDAR（書き込みアクセスの場合）。

イベントの意図

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

ボイスメール プロバイダ

新しいボイスメール プロバイダを使用すると、アプリケーションでボイスメールを ユーザーのすべてのボイスメールを 1 つのビジュアル プレゼンテーションに表示できます。たとえば 1 人のユーザーが、 1 つは電話のサービス プロバイダから、もう 1 つは VoIP またはその他の代替音声から 提供します。これらのアプリは、Voicemail Provider API を使用してボイスメールをデバイスに追加できます。組み込みの電話アプリに、すべてのボイスメールが統合された状態で表示されます。すべてのボイスメールを読み取れるアプリはシステムの電話アプリのみですが、ボイスメールを提供する各アプリは、システムに追加したボイスメールを読み取ることができます（ただし、他のサービスのボイスメールは読み取れません）。

この API では現在、サードパーティ アプリがボイスメールからのすべての ボイスメール API を使用する必要があるサードパーティ アプリは、ボイスメールに対応しているアプリのみです。 ユーザーに配信する必要があります

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

マルチメディア

Android 4.0 では、写真 動画、音楽。

メディア効果

新しいメディア エフェクト フレームワークを使用すると、画像や動画にさまざまな視覚効果を適用できます。たとえば、画像エフェクトを使用すると、赤目を修正したり、画像をグレースケールに変換したり、 明るさの調整、彩度の調整、画像の回転、魚眼効果の適用などを行えます。「 パフォーマンスを最大化するために、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 つあります。

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

EffectFactory にリストされているエフェクトはすべて、サポートが保証されています。 ただし、外部ライブラリから入手できる一部の追加エフェクトは、一部のデバイスでサポートされていません。 そのため、まず、 isEffectSupported()。

リモコン クライアント

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

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

プレーヤーが処理できるメディア コントロール入力を宣言するには、setTransportControlFlags() を RemoteControlClient。次のような FLAG_KEY_MEDIA_* フラグのセットを渡します。 FLAG_KEY_MEDIA_PREVIOUS、FLAG_KEY_MEDIA_NEXT。

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

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

実装例については、Random Music Player をご覧ください。Android 4.0 デバイスでリモコン クライアントを有効にし、Android 2.1 以前のデバイスのサポートを継続するなど、互換性ロジックを提供しています。

メディア プレーヤー

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

メディアの種類

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

  • HTTP/HTTPS ライブ ストリーミング プロトコル バージョン 3
  • ADTS Raw AAC 音声エンコード
  • WebP イメージ
  • Matroska 動画

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

カメラ

Camera クラスに、顔を検出して制御するための API が追加されました 測光エリアを指定します

顔検出

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

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

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

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

  • カメラの位置を基準として相対的に顔の境界を指定する Rect。 現在の画角
  • 1～100 の整数。オブジェクトが人間の顔であるというシステムの信頼度を示します。
  • 複数の顔を追跡するための一意の ID
  • 目と口の位置を示す複数の Point オブジェクト

注: 顔検出は、一部のデバイスではサポートされていない場合があります。 そのため、getMaxNumDetectedFaces() を呼び出して、戻り値が 指定することもできます。また、デバイスによっては目や口の認識に対応していないものもあります。 その場合、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 ビームは、デバイス間で NDEF メッセージを送信できる新しい NFC 機能です（このプロセスは「NDEF プッシュ」とも呼ばれます）。データ転送は、Android Beam をサポートする 2 台の Android デバイスが近接（約 4 cm）すると開始されます。通常は背面同士が接触します。NDEF メッセージ内のデータには、デバイス間で共有する任意のデータを含めることができます。たとえば、Android ビームを使用して、連絡先アプリが連絡先を共有し、YouTube が動画を共有し、ブラウザが URL を共有します。

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

  • アクティビティ内で push する 1 つの NdefMessage を定義します。

    送信するメッセージを設定するには、いつでも setNdefPushMessage() を呼び出します。たとえば、アクティビティの onCreate() メソッドでこのメソッドを呼び出して NdefMessage を渡すことができます。その後、アクティビティがアクティビティの最中に、別のデバイスで Android ビームが有効化されるたびに NdefMessage が他のデバイスに送信されます。

  • Android ビームの開始時に push する NdefMessage を定義します。

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

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

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

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

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

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

アプリが NFC API を使用して NDEF プッシュ メッセージを実行していない場合、Android にはデフォルトの動作が用意されています。1 つのデバイスでアプリがフォアグラウンドにあり、別の Android デバイスで Android Beam が呼び出されると、そのデバイスは、アプリを識別する Android アプリレコードを含む NDEF メッセージを受信します。受信側のデバイスに システムによって起動されます。インストールされていない場合は、Google Play が開き、 ユーザーにインストールしてもらう必要があります。

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

Wi-Fi P2P

Android は、ホットスポットやインターネット接続なしで、Android 搭載デバイスと他のデバイスタイプの間で Wi-Fi ピアツーピア（P2P）接続をサポートするようになりました（Wi-Fi Alliance の Wi-Fi Direct™ 認定プログラムに準拠）。Android フレームワークは、 他のデバイスの検出と接続を可能にする Wi-Fi P2P API のセット Wi-Fi P2P をサポートしており、 Bluetooth 接続。

新しいパッケージ android.net.wifi.p2p には、ピアツーピアを実行するためのすべての 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 Health Profile デバイスをサポートするようになりました。これにより、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 では sendAccessibilityEvent() メソッドの動作が変更されたことに注意してください。 4.0.以前のバージョンの Android と同様に、ユーザーがデバイスでユーザー補助サービスを有効にし、クリックやホバーなどの入力イベントが発生すると、sendAccessibilityEvent() が呼び出され、対応するビューに通知されます。これまでは sendAccessibilityEvent() を実装すると次のようになります。 AccessibilityEvent を初期化して AccessibilityManager に送信します。新しい動作では、ビューとその親がイベントにコンテキスト情報を追加できる追加のコールバック メソッドがいくつかあります。

  1. sendAccessibilityEvent() メソッドと sendAccessibilityEventUnchecked() メソッドは呼び出されると、 宛先: onInitializeAccessibilityEvent()

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

  2. 初期化後、イベントがテキスト入力対象のイベントの種類のいずれかである場合 情報を取得すると、ビューは dispatchPopulateAccessibilityEvent() への呼び出しを受け取ります。 onPopulateAccessibilityEvent() に従います 呼び出すことができます。

    通常、View のカスタム実装では、onPopulateAccessibilityEvent() を実装して テキストがない場合やandroid:contentDescriptionテキスト コンテンツをAccessibilityEventに送信する 不十分です。スペースに AccessibilityEvent の場合は、getText().add() を呼び出します。

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

View クラスを拡張するときに便利な上記の新しいメソッドに加えて、AccessibilityDelegate を拡張し、View setAccessibilityDelegate()。 その場合、ビュー内の各ユーザー補助メソッドは、 委任できます。たとえば、ビューは onPopulateAccessibilityEvent() の呼び出しを受け取ると、それを View.AccessibilityDelegate の同じメソッドを使用します。デリゲートで処理されないメソッドは、デフォルトの動作のためにビューに返されます。これにより、View クラスを拡張せずに、特定のビューに必要なメソッドのみをオーバーライドできます。

バージョン 4.0 より前の Android との互換性を維持しつつ、Android 4.0 のサポートも 最新バージョンの v4 サポート API で行うことができます。 ライブラリ（互換性パッケージ、r4 内） 新しいユーザー補助 API を提供する一連のユーティリティ クラスを使用して、 考えています

ユーザー補助サービス

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

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

  1. アプリケーションから AccessibilityEvent を受け取ると、 AccessibilityEvent.getRecord() を呼び出して特定の AccessibilityRecord を取得します（ あります。
  2. AccessibilityEvent または個々の AccessibilityRecord から getSource() を呼び出して、AccessibilityNodeInfo オブジェクトを取得できます。

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

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

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

その他のユーザー補助 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 エンジンを使用するアプリケーションには、 いくつかご紹介します

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

以前のバージョンの 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: これには、テキスト、画像、音声、 Synthesize、言語 / 地域、読み上げ速度、音声ピッチです。
  • 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>

このインテント フィルタは、アクティビティを管理するアクティビティであることをシステムに示す アプリのデータ使用量を追跡できますしたがって、ユーザーが現在のデバイスからのアプリの使用量を 設定アプリ、「View application settings」ボタンをクリックすると 設定アクティビティを使用して、アプリで使用するデータ量をユーザーが調整できるようにします。

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

Enterprise

Android 4.0 では、エンタープライズ アプリの機能が強化され、次の機能が追加されました。

VPN サービス

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

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

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) を呼び出して アクションバーからアプリ アイコンをクリックします。メインのアクションバーに何も残っていないので、 が非表示になります。残っているのは、上部のナビゲーション タブと下部のアクション アイテムだけです。 クリックします。

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

アクションバーにカスタム スタイルを適用する場合は、新しいスタイル プロパティ 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 ビューのインスタンスを指定するか、関連するマージンのパラメータを設定します。 避けるべきです

ApiDemos を参照 GridLayout を使用したサンプルをご覧ください。

TextureView

TextureView は、 動画や OpenGL シーンとして表示できます。SurfaceView と類似していますが、TextureView は通常のビューのように動作し、 他の View オブジェクトと同じように扱うことができます。たとえば、変換を適用したり、ViewPropertyAnimator を使用してアニメーション化したり、setAlpha() で不透明度を調整したりできます。

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

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

切り替えウィジェット

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

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

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

Android 3.0 で、ポップ コンテキスト メニューを作成するための PopupMenu が導入されました 指定したアンカー ポイント（通常は選択したアイテムのポイント）から上に移動します。Android 4.0 では、 PopupMenu に次のような便利な機能があります。

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

設定

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

システムテーマ

Android 4.0 をターゲットとするすべてのアプリのデフォルト テーマ（targetSdkVersion または minSdkVersion を “14" 以上に設定）は、「デバイスのデフォルト」テーマ Theme.DeviceDefault に変更されました。考えられる原因 ダークモードです。

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 では、 システムバーの表示設定が更新され、両方のシステムバーの動作をより正確に反映 ナビゲーション バー:

  • STATUS_BAR_HIDDEN フラグは SYSTEM_UI_FLAG_LOW_PROFILE フラグに置き換わります。このフラグを設定すると、「ロー プロファイル」が有効になります。選択します。 アクセスできます。システムバーのナビゲーション ボタンの暗さやその他の要素も非表示になります。これを有効にすると、システムのナビゲーション ボタンに気を散らすことなく、没入感のあるゲームを作成できます。
  • SYSTEM_UI_FLAG_VISIBLE フラグは、システムバーまたはナビゲーション バーの表示をリクエストする STATUS_BAR_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_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 クラスを使用すると、Property を宣言できます。 クラス Foo のオブジェクト 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" 以上に設定されている場合、すべてのウィンドウのハードウェア アクセラレーションがデフォルトで有効になります。一般に、ハードウェア アクセラレーションを使用すると、アニメーションがより滑らかになり、 ユーザー操作に対する全体的なパフォーマンスと応答性が向上します。

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

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

JNI の変更

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

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

この 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 プロバイダに書き込みアクセス権を付与します。

デバイスの機能

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

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

以前の API

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

今回リリースされた中でも特に注目すべき API をいくつかご紹介します。 スマートフォンにも搭載されています。

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

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

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

API レベル

Android 4.0 API には、システム自体に保存される整数識別子（14）が割り当てられます。「API レベル」と呼ばれるこの識別子により、システムは アプリケーションがシステムに対応しているかどうかを事前に確認できます。

Android 4.0 で導入された API をアプリで使用するには、 API レベル 14 または 高くなります。必要に応じて、ラベルの追加が必要になることがあります。 android:minSdkVersion="14" 属性を <uses-sdk> 要素です。

詳細については、API とは何か レベル