Android 4.4 API

API レベル: 19

Android 4.4(KITKAT)は Android プラットフォームの新しいリリースで、ユーザーとアプリ デベロッパー向けに新機能を提供します。このドキュメントでは、特に重要な新しい API の概要を説明します。

アプリ デベロッパーは、できるだけ早く SDK Manager から Android 4.4 のシステム イメージと SDK プラットフォームをダウンロードする必要があります。アプリをテストするための Android 4.4 を搭載したデバイスがない場合は、Android 4.4 システム イメージを使用して Android Emulator でアプリをテストします。次に、Android 4.4 プラットフォームに対してアプリをビルドして、最新の API の使用を開始します。

対象 API レベルを更新する

Android 4.4 を搭載するデバイス向けにアプリをより適切に最適化するには、targetSdkVersion"19" に設定し、Android 4.4 システム イメージにインストールしてテストし、この変更を反映したアップデートを公開する必要があります。

Android 4.4 の API を使用しながら古いバージョンもサポートするには、minSdkVersion でサポートされていない API を実行する前に、システムの API レベルをチェックする条件をコードに追加します。下位互換性の維持について詳しくは、異なるプラットフォーム バージョンのサポートをご覧ください。

API レベルの仕組みの詳細については、API レベルとはをご覧ください。

重要な動作変更

以前に Android 向けのアプリを公開したことがある場合は、アプリが Android 4.4 での変更の影響を受ける可能性があります。

アプリが外部ストレージから読み取る場合

Android 4.4 上で実行している場合、アプリに READ_EXTERNAL_STORAGE 権限がない限り、外部ストレージ上の共有ファイルを読み取ることはできません。つまり、getExternalStoragePublicDirectory() から返されるディレクトリ内のファイルは、権限がないとアクセスできなくなります。ただし、getExternalFilesDir() が提供するアプリ固有のディレクトリのみにアクセスする必要がある場合は、READ_EXTERNAL_STORAGE 権限は必要ありません。

アプリで WebView を使用する場合

Android 4.4 でアプリを実行する場合、特にアプリの targetSdkVersion を「19」以上にアップデートすると、アプリの動作が異なることがあります。

WebView クラスと関連 API の基盤となるコードが、Chromium ソースコードの最新のスナップショットに基づいてアップグレードされました。これにより、パフォーマンスのさまざまな改善、HTML5 の新機能のサポート、WebView コンテンツのリモート デバッグのサポートが追加されました。このアップグレードの対象範囲は、アプリで WebView を使用している場合、その動作が影響を受ける可能性があることを意味します。既知の動作変更は記載されており、主にアプリの targetSdkVersion を「19」以降にアップデートした場合にのみアプリに影響します。新しい WebView は「後方モード」で動作し、API レベル 18 以下をターゲットとするアプリで一部のレガシー機能を提供します。アプリが以前のバージョンの WebView の不明な動作に依存している可能性があります。

そのため、既存のアプリで WebView を使用している場合は、できるだけ早く Android 4.4 でテストすることが重要です。targetSdkVersion を「19」以上に更新した場合のアプリへの影響については、Android 4.4 での WebView への移行をご覧ください。

アプリで AlarmManager を使用する場合

アプリの targetSdkVersion を「19」以上に設定すると、set() または setRepeating() を使用して作成したアラームは不正確になります。

Android では、電力効率を高めるために、ほぼ同じ時間に発生するすべてのアプリからのアラームを 1 つにまとめて、各アラームを処理するために何度もデバイスを復帰させるのではなく、1 回でまとめてバッテリーを復帰させるようになりました。

正確な時刻にアラームが関連付けられていないものの、特定の時間範囲(午後 2 時から午後 4 時など)にアラームを呼び出すことが重要な場合は、新しい setWindow() メソッドを使用できます。このメソッドは、アラームの「最も早い」時刻と、システムがアラームを呼び出す必要がある最も早い時刻に続く「時間枠」を受け入れます。

アラームを正確な時刻に固定する必要がある場合(カレンダーの予定のリマインダーなど)は、新しい setExact() メソッドを使用できます。

この不正確なバッチ処理の動作は、更新されたアプリにのみ適用されます。targetSdkVersion を「18」以下に設定している場合、Android 4.4 でのアラームは以前のバージョンの動作を続けます。

アプリが ContentResolver を使用してデータを同期する場合

アプリの targetSdkVersion を「19」以上に設定している場合、addPeriodicSync() を使用して同期を作成すると、デフォルトのフレックス間隔(指定した期間の約 4%)で同期オペレーションが実行されます。たとえば、ポーリング頻度が 24 時間の場合、同期処理は毎日正確に同じ時刻に行われるのではなく、毎日約 1 時間の時間枠内で行われます。

同期オペレーションのフレックス間隔を独自に指定するには、新しい requestSync() メソッドの使用を開始する必要があります。詳しくは、同期アダプターに関する以下のセクションをご覧ください。

このフレックス間隔の動作は、更新されたアプリにのみ適用されます。targetSdkVersion を「18」以下に設定している場合、Android 4.4 で実行したとき、既存の同期リクエストは以前のバージョンと同じように動作します。

印刷フレームワーク

Android には、Wi-Fi、Bluetooth、その他のサービス経由で接続されたプリンタを使用して、あらゆるドキュメントを印刷できるようにする完全なフレームワークが組み込まれています。ドキュメントを印刷するアプリと、印刷ジョブをプリンタに配信するサービスとの間のトランザクションは、システムで処理されます。android.print フレームワークには、印刷ドキュメントを指定してシステムに配信するために必要な API がすべて用意されています。印刷ジョブに実際に必要な API は、コンテンツによって異なります。

汎用コンテンツの印刷

UI のコンテンツをドキュメントとして出力する場合は、まず PrintDocumentAdapter のサブクラスを作成する必要があります。このクラス内で、指定された印刷プロパティに基づいてレイアウトを確立する onLayout() や、印刷可能なコンテンツを ParcelFileDescriptor にシリアル化する onWrite() など、いくつかのコールバック メソッドを実装する必要があります。

コンテンツを ParcelFileDescriptor に書き込むには、PDF を渡す必要があります。新しい PdfDocument API では、getCanvas() から Canvas を指定することにより、印刷可能なコンテンツを描画できる便利な方法が提供されます。次に、writeTo() メソッドを使用して、PdfDocumentParcelFileDescriptor に書き込みます。

PrintDocumentAdapter の実装を定義したら、PrintManager メソッドの print() を使用してユーザーのリクエストに応じて印刷ジョブを実行できます。このメソッドは引数の 1 つとして PrintDocumentAdapter を受け取ります。

画像の印刷

写真などのビットマップだけを印刷する場合は、サポート ライブラリのヘルパー API がすべての処理を行います。PrintHelper の新しいインスタンスを作成し、setScaleMode() でスケールモードを設定してから、BitmapprintBitmap() に渡すだけです。これで完了です。ライブラリは、システムとの残りのすべてのやり取りを処理して、ビットマップをプリンタに配信します。

印刷サービスの構築

プリンタ OEM は、android.printservice フレームワークを使用することで、Android デバイスのプリンタとの相互運用を実現できます。印刷サービスは APK としてビルド、配布でき、ユーザーは APK をデバイスにインストールできます。印刷サービスアプリは、主に PrintService クラスをサブクラス化することでヘッドレス サービスとして動作します。システムから印刷ジョブを受信し、適切なプロトコルを使用してジョブをプリンタと通信します。

アプリ コンテンツを印刷する方法については、コンテンツの印刷をご覧ください。

SMS プロバイダ

Telephony のコンテンツ プロバイダ(「SMS プロバイダ」)は、デバイス上の SMS および MMS メッセージの読み書きをアプリに許可します。SMS や MMS のメッセージの受信、下書き、送信、保留中などの表が表示されます。

Android 4.4 以降では、システム設定で「デフォルトの SMS アプリ」を選択できます。選択すると、デフォルトの SMS アプリのみが SMS プロバイダに書き込めます。また、ユーザーが SMS を受信したときはデフォルトの SMS アプリのみが SMS_DELIVER_ACTION ブロードキャストを受信し、ユーザーが MMS を受信したときに WAP_PUSH_DELIVER_ACTION ブロードキャストを受信します。デフォルトの SMS アプリは、新しいメッセージを送受信する際に SMS プロバイダに詳細を書き込む役割を担います。

デフォルトの SMS アプリとして選択されていない他のアプリは、SMS プロバイダの読み取りのみが可能ですが、SMS_RECEIVED_ACTION ブロードキャスト(複数のアプリに配信できる中断不可能なブロードキャスト)をリッスンすることで、新しい SMS の到着時に通知を受けることもできます。このブロードキャストは、デフォルトの SMS アプリとして選択されていなくても、電話番号の確認など、特別な受信メッセージを読み取る必要があるアプリを対象としています。

詳しくは、ブログ投稿 Getting Your SMS Apps Ready for KitKat をご覧ください。

ワイヤレスと接続

ホストカード エミュレーション

Android アプリで、データ交換に APDU を使用する ISO14443-4(ISO-DEP)NFC カードをエミュレートできるようになりました(ISO7816-4 で規定)。これにより、Android 4.4 を搭載する NFC 対応デバイスは、複数の NFC カードを同時にエミュレートし、NFC 決済端末やその他の NFC リーダーは、アプリケーション識別子(AID)に基づいて適切な NFC カードでのトランザクションを開始できます。

アプリでこれらのプロトコルを使用する NFC カードをエミュレートする場合は、HostApduService クラスに基づいてサービス コンポーネントを作成します。一方、アプリでカード エミュレーションにセキュア エレメントを使用する場合は、OffHostApduService クラスをベースとするサービスを作成する必要があります。このクラスはトランザクションに直接関係しませんが、セキュア エレメントで処理する AID を登録するために必要です。

詳しくは、NFC カード エミュレーション ガイドをご覧ください。

NFC リーダー モード

新しい NFC リーダー モードを使用すると、すべての NFC アクティビティがフォアグラウンドで目的の種類のタグを読み取るように制限できます。enableReaderMode() を使用してアクティビティでリーダーモードを有効にできます。これにより、新しいタグが検出されたときにコールバックを受け取る NfcAdapter.ReaderCallback の実装が提供されます。

この新機能とホストカード エミュレーションを組み合わせることで、Android はモバイル決済インターフェースの両端で動作できるようになります。一方のデバイスは決済端末(リーダーモードのアクティビティを実行するデバイス)として動作し、別のデバイスは決済クライアント(NFC カードをエミュレートするデバイス)として動作します。

赤外線送信機

赤外線(IR)送信機を含むデバイスで実行する場合、ConsumerIrManager API を使用して IR 信号を送信できるようになりました。ConsumerIrManager のインスタンスを取得するには、引数に CONSUMER_IR_SERVICE を指定して getSystemService() を呼び出します。その後、getCarrierFrequencies() でデバイスでサポートされている IR 周波数をクエリし、transmit() で目的の周波数と信号パターンを渡すことで信号を送信できます。

最初に hasIrEmitter() を呼び出して、デバイスに IR 送信機が搭載されているかどうかを必ず確認する必要があります。ただし、アプリが IR 送信機を搭載しているデバイスにのみ対応している場合は、マニフェストに "android.hardware.consumerir"FEATURE_CONSUMER_IR)の <uses-feature> 要素を含める必要があります。

マルチメディア

アダプティブ再生

アダプティブ動画再生のサポートが MediaCodec API で利用できるようになりました。これにより、Surface で再生する際に解像度をシームレスに変更できます。新しい解像度のデコーダ入力フレームをフィードすると、出力バッファの解像度が大幅にギャップなしに変化します。

アダプティブ再生を有効にするには、アプリがコーデックに必要な最大解像度(KEY_MAX_WIDTHKEY_MAX_HEIGHT)を指定する 2 つのキーを MediaFormat に追加します。これらを MediaFormat に追加したら、configure()MediaFormatMediaCodec インスタンスに渡します。

コーデックは、これらの値と同じかそれ以下の解像度間でシームレスに移行します。サポートされているプロファイルの制限内であれば、指定された最大値よりも大きな解像度をサポートするコーデックもありますが、大きな解像度への移行はシームレスに行えない場合があります。

H.264 動画のデコード中に解像度を変更するには、引き続き MediaCodec.queueInputBuffer() を使用してフレームをキューに入れます。ただし、必ず新しいシーケンス パラメータ セット(SPS)とピクチャ パラメータ セット(PPS)の値を、Instantaneous Decoder Refresh(IDR)フレームとともに単一のバッファに含めてください。

ただし、アダプティブ再生のコーデックを構成する前に、FEATURE_AdaptivePlaybackisFeatureSupported(String) を呼び出して、デバイスがアダプティブ再生をサポートしていることを確認する必要があります。

注: アダプティブ再生のサポートはベンダー固有です。コーデックによっては、解像度を高めるために多くのメモリが必要になる場合があります。そのため、デコードするソース マテリアルに基づいて最大解像度を設定する必要があります。

オンデマンドの音声のタイムスタンプ

音声と動画の同期を容易にするために、新しい AudioTimestamp クラスは、AudioTrack によって処理される音声ストリームの特定の「フレーム」に関するタイムラインの詳細を提供します。利用可能な最新のタイムスタンプを取得するには、AudioTimestamp オブジェクトをインスタンス化して getTimestamp() に渡します。タイムスタンプのリクエストが成功すると、AudioTrack インスタンスに、フレーム単位の位置と、そのフレームが表示または提示を確定した推定時刻が入力されます。

AudioTimestampnanoTime の値(単調)を使用して、framePosition と比較して最も近い関連動画フレームを見つけることができます。これにより、動画フレームをドロップ、複製、または補間して音声に一致させることができます。または、nanoTime の値と将来の動画フレームの推定時間の差分時間(サンプルレートを考慮)を決定して、どの音声フレームが動画フレームと同じタイミングで想定されるかを予測することもできます。

サーフェス画像リーダー

新しい ImageReader API を使用すると、Surface にレンダリングされる画像バッファに直接アクセスできます。ImageReader は、静的メソッド newInstance() で取得できます。次に、getSurface() を呼び出して新しい Surface を作成し、MediaPlayerMediaCodec などのプロデューサで画像データを配信します。サーフェスから新しい画像が利用可能になったときに通知を受け取るには、ImageReader.OnImageAvailableListener インターフェースを実装して setOnImageAvailableListener() に登録します。

Surface にコンテンツを描画すると、新しい画像フレームが利用可能になるたびに ImageReader.OnImageAvailableListeneronImageAvailable() に対する呼び出しを受け取り、対応する ImageReader が提供されます。acquireLatestImage() または acquireNextImage() を呼び出すことで、ImageReader を使用してフレームの画像データを Image オブジェクトとして取得できます。

Image オブジェクトを使用すると、ByteBuffer 内の画像のタイムスタンプ、形式、サイズ、ピクセルデータに直接アクセスできます。ただし、Image クラスで画像を解釈するためには、ImageFormat または PixelFormat の定数で定義された型のいずれかに従ってフォーマットする必要があります。

ピークと RMS の測定

Visualizer.MeasurementPeakRms の新しいインスタンスを作成して getMeasurementPeakRms() に渡すことで、Visualizer から現在の音声ストリームのピークと RMS をクエリできるようになりました。このメソッドを呼び出すと、指定された Visualizer.MeasurementPeakRms のピーク値と RMS 値が最新の測定値に設定されます。

ラウドネス エンハンサー

LoudnessEnhancer は、MediaPlayer または AudioTrack の可聴音量を上げることができる、AudioEffect の新しいサブクラスです。これは、他のメディアの再生中に音声トラックの音量を上げるために、上記の新しい getMeasurementPeakRms() メソッドと組み合わせて使用すると特に便利です。

リモコン

Android 4.0(API レベル 14)で RemoteControlClient API が導入され、ロック画面でのメディア コントロールなど、リモート クライアントからのメディア コントローラ イベントをメディアアプリが消費できるようになりました。新しい RemoteController API を使用して独自のリモート コントローラを作成できるようになりました。これにより、RemoteControlClient と統合したあらゆるメディアアプリの再生をコントロールできる、革新的なアプリや周辺機器の開発が可能になります。

リモート コントローラは、必要に応じてユーザー インターフェースを実装できますが、ユーザーのメディアアプリにメディアボタン イベントを配信するには、NotificationListenerService クラスを拡張して RemoteController.OnClientUpdateListener インターフェースを実装するサービスを作成する必要があります。適切なプライバシー制限が提供され、ユーザーがシステムのセキュリティ設定でアプリを通知リスナーとして有効にする必要があるため、ベースとして NotificationListenerService を使用することは重要です。

NotificationListenerService クラスには、実装が必要な抽象メソッドがいくつか含まれていますが、メディア再生を処理するメディア コントローラ イベントのみに関心がある場合は、それらの実装を空のままにして、代わりに RemoteController.OnClientUpdateListener メソッドに集中できます。

リモコンからの評価

Android 4.4 は、リモート コントロール クライアント(RemoteControlClient でメディア コントロール イベントを受信するアプリ)の既存の機能をベースに、ユーザーがリモート コントローラから現在のトラックを評価する機能を追加しています。

新しい Rating クラスは、ユーザーの評価に関する情報をカプセル化します。評価は、評価スタイル(RATING_HEARTRATING_THUMB_UP_DOWNRATING_3_STARSRATING_4_STARSRATING_5_STARSRATING_PERCENTAGE)と、そのスタイルに適した評価値によって定義されます。

ユーザーがリモコンからトラックを評価できるようにするには:

ユーザーがリモコンから評価を変更したときにコールバックを受け取るには、新しい RemoteControlClient.OnMetadataUpdateListener インターフェースを実装し、インスタンスを setMetadataUpdateListener() に渡します。ユーザーが評価を変更すると、RemoteControlClient.OnMetadataUpdateListeneronMetadataUpdate() への呼び出しを受け取り、キーとして RATING_KEY_BY_USER を、値として Rating オブジェクトを渡します。

字幕

VideoView が HTTP Live Stream(HLS)動画の再生時に WebVTT 字幕トラックをサポートするようになりました。ユーザーがシステム設定で定義した字幕設定に従って字幕トラックが表示されます。

addSubtitleSource() メソッドを使用して、VideoView に WebVTT 字幕トラックを指定することもできます。このメソッドは、字幕データを保持する InputStream と、字幕データの形式(createSubtitleFormat() を使用して指定できる)を指定する MediaFormat オブジェクトを受け入れます。字幕は、ユーザーの好みに応じて動画上にも重ねて表示されます。

VideoView を使用して動画コンテンツを表示しない場合、字幕オーバーレイをユーザーの字幕設定にできる限り一致させる必要があります。新しい CaptioningManager API を使用すると、ユーザーの字幕設定(CaptioningManager.CaptionStyle で定義されたスタイル(書体や色など)を含む)をクエリできます。動画の開始後にユーザーが設定を調整した場合、CaptioningManager.CaptioningChangeListener のインスタンスを登録して設定変更をリッスンし、設定が変更されたときにコールバックを受信してから、必要に応じて字幕を更新する必要があります。

アニメーションとグラフィック

シーンと遷移

新しい android.transition フレームワークには、ユーザー インターフェースのさまざまな状態間のアニメーションを容易にする API が用意されています。主な機能として、UI の各状態を個別のレイアウトを作成することで、「シーン」と呼ばれる個別の状態を定義できる機能があります。あるシーンから別のシーンにアニメーションを付けるには「遷移」を実行します。これは、現在のシーンから次のシーンにレイアウトを変更するために必要なアニメーションを計算します。

2 つのシーンを切り替えるには、通常、次の手順を行う必要があります。

  1. 変更する UI コンポーネントを含む ViewGroup を指定します。
  2. 変更の最終結果(次のシーン)を表すレイアウトを指定します。
  3. レイアウトの変化をアニメーション化する遷移の種類を指定します。
  4. 移行を実行します。

ステップ 1 とステップ 2 は、Scene オブジェクトを使用して行うことができます。Scene には、シーンの親ビューやシーンのレイアウトなど、遷移の実行に必要なレイアウトのプロパティを記述するメタデータが含まれます。Scene を作成するには、クラス コンストラクタまたは静的メソッド getSceneForLayout() を使用します。

次に、TransitionManager を使用してステップ 3 と 4 を行う必要があります。1 つは、Scene を静的メソッド go() に渡すことです。これにより、現在のレイアウト内でシーンの親ビューを見つけ、Scene で定義されたレイアウトに到達するために子ビューで遷移を実行します。

または、Scene オブジェクトを作成する必要はなく、代わりに beginDelayedTransition() を呼び出して、変更するビューを含む ViewGroup を指定できます。次に、ターゲット ビューを追加、削除、または再構成します。必要に応じて変更がレイアウトされると、遷移が開始し、影響を受けるすべてのビューのアニメーション化が始まります。

さらに詳細な制御を行うには、プロジェクトの res/transition/ ディレクトリにある XML ファイルを使用して、事前定義のシーン間で発生する移行のセットを定義できます。<transitionManager> 要素内で、1 つ以上の <transition> タグを指定します。このタグは、それぞれシーン(レイアウト ファイルへの参照)とそのシーンの開始時または終了時に適用する遷移を指定します。次に、inflateTransitionManager() を使用して、この遷移のセットをインフレートします。返された TransitionManager を使用して、transitionTo() で各遷移を実行し、<transition> タグのいずれかで表される Scene を渡します。TransitionManager API を使用して、一連の遷移をプログラムで定義することもできます。

遷移を指定するときは、FadeChangeBounds など、Transition のサブクラスで定義された複数の事前定義型を使用できます。遷移の種類を指定しない場合、デフォルトでは AutoTransition が使用されます。これにより、必要に応じてビューのフェード、移動、サイズ変更が自動的に行われます。さらに、これらのクラスを拡張して、お好みのアニメーションを実行することで、カスタム遷移を作成することもできます。カスタム遷移ではプロパティの変更をトラッキングし、その変更に基づいてアニメーションを作成できます。たとえば、ビューの「rotation」プロパティの変更をリッスンして変更をアニメーション化する Transition のサブクラスを提供できます。

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

アニメーターによる一時停止

Animator API で、メソッド pause()resume() を使用して進行中のアニメーションを一時停止および再開できるようになりました。

アニメーションの状態をトラッキングするには、Animator.AnimatorPauseListener インターフェースを実装します。このインターフェースは、アニメーションの一時停止時と再開時のコールバック(pause()resume())を提供します。次に、addPauseListener() を使用して Animator オブジェクトにリスナーを追加します。

または、AnimatorListenerAdapter 抽象クラスをサブクラス化することもできます。このクラスには、Animator.AnimatorPauseListener で定義された一時停止と再開のコールバックの空の実装が追加されています。

再利用可能なビットマップ

BitmapFactory の変更可能なビットマップを再利用して、他のビットマップをデコードできるようになりました。ただし、デコードされたビットマップのバイト数(getByteCount() から利用可能)が、再利用されたビットマップに割り当てられたバイト数(getAllocationByteCount() から利用可能)以下であれば、新しいビットマップのサイズが違っていてもデコードできるようになります。詳しくは、inBitmap をご覧ください。

Bitmap の新しい API を使用すると、同様の再構成を BitmapFactory の外部で再利用できます(手動ビットマップ生成またはカスタム デコード ロジック)。setHeight() メソッドと setWidth() メソッドを使用してビットマップのディメンションを設定し、基になるビットマップの割り当てに影響を与えることなく、setConfig() で新しい Bitmap.Config を指定できるようになりました。reconfigure() メソッドを使用すると、これらの変更を 1 回の呼び出しで簡単に組み合わせることもできます。

ただし、基になるピクセル バッファが予測可能な方法で再マッピングされないため、ビューシステムで現在使用されているビットマップを再構成しないでください。

ユーザー コンテンツ

ストレージ アクセス フレームワーク

以前のバージョンの Android では、アプリで別のアプリから特定の種類のファイルを取得する場合、ACTION_GET_CONTENT アクションを使用してインテントを呼び出す必要があります。アプリにインポートしたいファイルをリクエストする場合は、このアクションが引き続き適切な方法です。ただし、Android 4.4 には ACTION_OPEN_DOCUMENT アクションが導入されています。これにより、ユーザーは特定のタイプのファイルを選択し、アプリにファイルをインポートしなくても、そのファイルへの長期的な読み取りアクセス権(場合によっては書き込みアクセス権あり)をアプリに付与できます。

ファイル用のストレージ サービス(クラウド保存サービスなど)を提供するアプリを開発する場合は、新しい DocumentsProvider クラスのサブクラスとしてコンテンツ プロバイダを実装することで、この統合 UI を利用してファイルを選択できます。DocumentsProvider のサブクラスには、PROVIDER_INTERFACE アクション("android.content.action.DOCUMENTS_PROVIDER")を受け入れるインテント フィルタを含める必要があります。次に、DocumentsProvider に次の 4 つの抽象メソッドを実装する必要があります。

queryRoots()
DocumentsContract.Root で定義された列を使用して、ドキュメント ストレージのすべてのルート ディレクトリを記述する Cursor を返す必要があります。
queryChildDocuments()
DocumentsContract.Document で定義された列を使用して、指定したディレクトリ内のすべてのファイルを記述する Cursor を返す必要があります。
queryDocument()
DocumentsContract.Document で定義された列を使用して、指定されたファイルを記述する Cursor を返す必要があります。
openDocument()
このメソッドは、指定されたファイルを表す ParcelFileDescriptor を返す必要があります。ユーザーがファイルを選択し、クライアント アプリが openFileDescriptor() を呼び出してファイルへのアクセスをリクエストすると、このメソッドが呼び出されます。

詳細については、ストレージ アクセス フレームワーク ガイドをご覧ください。

外部ストレージへのアクセス

エミュレートされたストレージと SD カードがデバイスにある場合など、セカンダリ外部ストレージ メディアにあるアプリ固有のファイルの読み取りと書き込みができるようになりました。新しいメソッド getExternalFilesDirs() は、File オブジェクトの配列を返すことを除けば、既存の getExternalFilesDir() メソッドと同じように機能します。このメソッドで返されたパスを読み書きする前に、File オブジェクトを新しい getStorageState() メソッドに渡して、ストレージが現在使用可能であることを確認します。

アプリ固有のキャッシュ ディレクトリと OBB ディレクトリにアクセスするための他のメソッドにも、それぞれ対応するバージョンとして、セカンダリ ストレージ デバイスへのアクセスを提供するバージョン getExternalCacheDirs()getObbDirs() が追加されました。

返された File 配列の最初のエントリは、デバイスのプライマリ外部ストレージと見なされます。これは、getExternalFilesDir() などの既存のメソッドから返される File と同じです。

注: Android 4.4 以降では、上記の方法で外部ストレージのアプリ固有の領域にのみアクセスする必要がある場合に、アプリが WRITE_EXTERNAL_STORAGE または READ_EXTERNAL_STORAGE を取得することは、プラットフォームの要件ではなくなりました。ただし、getExternalStoragePublicDirectory() が提供する外部ストレージの共有可能なリージョンにアクセスする場合は、権限が必要です。

同期アダプター

ContentResolver の新しい requestSync() メソッドを使用すると、SyncRequest.Builder で作成できる新しい SyncRequest オブジェクトにリクエストをカプセル化することで、ContentProvider の同期リクエストを定義する手順の一部を簡素化できます。SyncRequest のプロパティは、既存の ContentProvider 同期呼び出しと同じ機能を提供しますが、setDisallowMetered() を有効にすることで、ネットワークが従量制の場合は同期を中止するように指定する機能が追加されています。

ユーザー入力

新しいセンサータイプ

新しい TYPE_GEOMAGNETIC_ROTATION_VECTOR センサーは、磁力計に基づく回転ベクトルデータを提供します。これは、ジャイロスコープが利用できない場合や、スマートフォンがスリープ中のデバイスの向きを記録するバッチ処理センサー イベントとともに使用する場合に、TYPE_ROTATION_VECTOR センサーの代替として役立ちます。このセンサーの消費電力は TYPE_ROTATION_VECTOR よりも少ないものの、イベントデータノイズが多くなりやすいため、ユーザーが屋外にいるときに最も効果的です。

Android では、ハードウェアに内蔵の歩数センサーもサポートされるようになりました。

TYPE_STEP_DETECTOR
このセンサーは、ユーザーが歩くたびにイベントをトリガーします。このセンサーは、ユーザーが 1 歩進むたびに、値が 1.0 で、歩数が発生した時刻を示すタイムスタンプを含むイベントを配信します。
TYPE_STEP_COUNTER
このセンサーは、歩数が検出されるたびにイベントをトリガーしますが、代わりに、このセンサーがアプリで最初に登録された後の累積歩数の合計を配信します。

この 2 つの歩行センサーの結果は、必ずしも同じになるとは限りません。TYPE_STEP_COUNTER イベントは TYPE_STEP_DETECTOR イベントよりもレイテンシが高くなりますが、これは TYPE_STEP_COUNTER アルゴリズムが誤検出を排除するためにより多くの処理を行うためです。そのため、TYPE_STEP_COUNTER はイベントの配信に時間がかかる場合がありますが、結果はより正確になります。

どちらの歩数センサーも、ハードウェアに依存するため(Nexus 5 が最初に搭載されたデバイスです)、FEATURE_SENSOR_STEP_DETECTOR 定数と FEATURE_SENSOR_STEP_COUNTER 定数を使用して、hasSystemFeature() で可用性を確認する必要があります。

バッチ処理済みのセンサー イベント

デバイスの電力をより適切に管理するために、SensorManager API を使用して、システムがセンサー イベントのバッチをアプリに配信する頻度を指定できるようになりました。これにより、一定期間にアプリが使用できる実際のセンサー イベントの数が減ることはなく、センサーの更新で SensorEventListener を呼び出す頻度が減ります。つまり、各イベントが発生したときにすぐにアプリに配信するのではなく、一定期間に発生したすべてのイベントを保存して、一度にアプリに配信します。

バッチ処理を提供するために、SensorManager クラスでは、「最大レポート レイテンシ」を指定できる registerListener() メソッドの 2 つの新しいバージョンが追加されています。この新しいパラメータでは、SensorEventListener で許容される新しいセンサー イベントの配信の最大遅延時間を指定します。たとえば、バッチ レイテンシを 1 分に指定した場合、onSensorChanged() メソッドを連続して呼び出し、最近のバッチ イベントのセットを 1 分以内の間隔で配信します(バッチ処理されたイベントごとに 1 回ずつ)。センサー イベントは最大レポート レイテンシ値より長く遅延することはありませんが、他のアプリが同じセンサーに対してより短いレイテンシを要求した場合は、それより早く到着する可能性があります。

ただし、センサーは、CPU が動作しているときのみ、レポートのレイテンシに基づいて、バッチ処理されたイベントをアプリに配信することに注意してください。バッチ処理をサポートするハードウェア センサーは、CPU がスリープしている間もセンサー イベントの収集を継続しますが、バッチ処理されたイベントをアプリに配信するために CPU を起動することはできません。センサーは、最終的にイベントのメモリが不足すると、最新のイベントを保存するために、最も古いイベントを破棄し始めます。センサーがメモリがいっぱいになる前にデバイスをスリープ状態から復帰させ、flush() を呼び出して最新のイベント バッチをキャプチャすることで、イベントの損失を回避できます。メモリがいっぱいになり、フラッシュする必要があるタイミングを推定するには、getFifoMaxEventCount() を呼び出して保存できるセンサー イベントの最大数を取得し、その値をアプリが各イベントに必要なレートで割ります。この計算を使用して、ServiceSensorEventListener を実装する)を呼び出してセンサーをフラッシュする AlarmManager でウェイク アラームを設定します。

注: すべてのデバイスがセンサー イベントのバッチ処理をサポートしているわけではありません。これは、ハードウェア センサーによるサポートが必要なためです。ただし、Android 4.4 以降では、常に新しい registerListener() メソッドを使用する必要があります。デバイスがバッチ処理をサポートしていない場合、システムはバッチ レイテンシの引数を無視して、センサー イベントをリアルタイムで配信するためです。

コントローラ ID

Android は、接続されている各コントローラを、getControllerNumber() でクエリできる一意の整数で識別するようになりました。これにより、各コントローラをゲーム内の別のプレーヤーに簡単に関連付けることができます。各コントローラの番号は、コントローラの接続解除、接続、再設定によって変わる可能性があるため、InputManager.InputDeviceListener のインスタンスを登録して、各入力デバイスに対応するコントローラ番号を追跡する必要があります。次に、変更が発生したときに InputDevice ごとに getControllerNumber() を呼び出します。

接続済みのデバイスは、getProductId()getVendorId() から入手できる製品 ID とベンダー ID も提供するようになりました。デバイスで利用可能なキーのセットに基づいてキーマッピングを変更する必要がある場合は、hasKeys(int...) を使用してデバイスにクエリを実行し、特定のキーが使用可能かどうかを確認できます。

ユーザー インターフェース

没入型全画面モード

画面全体に表示されるレイアウトをアプリで提供するために、setSystemUiVisibility() の新しい SYSTEM_UI_FLAG_IMMERSIVE フラグ(SYSTEM_UI_FLAG_HIDE_NAVIGATION と組み合わせる場合)を使用すると、新しい没入型全画面モードが有効になります。没入型全画面モードが有効になっている間は、アクティビティは引き続きすべてのタッチイベントを受信します。システムバーが通常表示される領域を内側にスワイプしてシステムバーを表示できます。これにより、SYSTEM_UI_FLAG_HIDE_NAVIGATION フラグ(および適用されている場合は SYSTEM_UI_FLAG_FULLSCREEN フラグ)がクリアされ、システムバーが引き続き表示されます。しばらくしてシステムバーを再び非表示にする場合は、代わりに SYSTEM_UI_FLAG_IMMERSIVE_STICKY フラグを使用します。

半透明のシステムバー

新しいテーマ Theme.Holo.NoActionBar.TranslucentDecorTheme.Holo.Light.NoActionBar.TranslucentDecor でシステムバーを半透明にできるようになりました。半透明のシステムバーを有効にすると、システムバーの背後の領域がレイアウトで埋められます。そのため、レイアウトの中でシステムバーに覆われてはならない部分に対して fitsSystemWindows も有効にする必要があります。

カスタムテーマを作成する場合は、これらのテーマのいずれかを親テーマとして設定するか、テーマに windowTranslucentNavigation および windowTranslucentStatus スタイル プロパティを含めます。

通知リスナーの強化

Android 4.3 で NotificationListenerService API が追加され、システムから新しい通知が投稿されたときに、アプリがその通知を受け取れるようになりました。Android 4.4 では、通知リスナーは通知の追加メタデータと通知のアクションに関する詳細情報を取得できます。

新しい Notification.extras フィールドには、通知ビルダーに EXTRA_TITLEEXTRA_PICTURE などの追加のメタデータを配信する Bundle が含まれています。新しい Notification.Action クラスは、通知に添付されたアクションの特性を定義します。この特性は、新しい actions フィールドから取得することができます。

RTL レイアウトのドローアブル ミラーリング

以前のバージョンの Android では、右から左へのレイアウトのために横向きを反転させる画像がアプリに含まれている場合、ミラーリングした画像を drawables-ldrtl/ リソース ディレクトリに含める必要があります。これで、ドローアブル リソースで autoMirrored 属性を有効にするか、setAutoMirrored() を呼び出すことで、画像が自動的にミラーリングされるようになりました。有効にすると、レイアウト方向が右から左になると Drawable が自動的にミラーリングされます。

ユーザー補助

View クラスを使用すると、XML レイアウトに新しい accessibilityLiveRegion 属性を追加するか、setAccessibilityLiveRegion() を呼び出すことで、新しいテキスト コンテンツで動的に更新される UI の部分に「ライブ領域」を宣言できるようになりました。たとえば、テキスト フィールドに「パスワードの誤り」の通知を表示するログイン画面は、ライブ領域としてマークして、変更されたときにスクリーン リーダーでメッセージが読み上げられるようにする必要があります。

ユーザー補助サービスを提供するアプリは、AccessibilityNodeInfo.CollectionInfoAccessibilityNodeInfo.CollectionItemInfo を使用してリストビューやグリッドビューなど、ビュー コレクションに関する情報を提供する新しい API を使用して、機能を強化することもできます。

アプリの権限

特定の新しい API を使用するために、アプリが <uses-permission> タグでリクエストする必要がある新しい権限は次のとおりです。

INSTALL_SHORTCUT
ランチャーへのショートカットのインストールをアプリに許可します
UNINSTALL_SHORTCUT
ランチャーのショートカットをアンインストールすることをアプリに許可します
TRANSMIT_IR
デバイスの IR 送信機の使用をアプリに許可します(利用可能な場合)

注: Android 4.4 以降では、getExternalFilesDir() などのメソッドを使用して外部ストレージのアプリ固有の領域にアクセスする場合、アプリで WRITE_EXTERNAL_STORAGE または READ_EXTERNAL_STORAGE を取得する必要がなくなりました。ただし、getExternalStoragePublicDirectory() が提供する外部ストレージの共有可能なリージョンにアクセスする場合は、引き続き権限が必要です。

デバイスの機能

次に示す新しいデバイス機能は、<uses-feature> タグを使用して宣言することで、アプリの要件を宣言したり、Google Play でフィルタリングを有効にしたり、実行時にチェックしたりできます。

FEATURE_CONSUMER_IR
このデバイスは、一般ユーザー向け IR デバイスと通信できます。
FEATURE_DEVICE_ADMIN
デバイスが、デバイス管理者によるデバイス ポリシーの適用をサポートしている。
FEATURE_NFC_HOST_CARD_EMULATION
デバイスが、ホストベースの NFC カード エミュレーションをサポートしている。
FEATURE_SENSOR_STEP_COUNTER
デバイスは、ハードウェアの歩数計を内蔵しています。
FEATURE_SENSOR_STEP_DETECTOR
このデバイスには、ハードウェア歩行検出機能が搭載されています。

Android 4.4 における API の変更点について詳しくは、API の違いレポートをご覧ください。