このページは Cloud Translation API によって翻訳されました。

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 回のスリープ状態から復帰させるようになりました。

アラームが正確な時刻に関連付けられていなくても、特定の時間範囲（午後 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() メソッドを使用して、PdfDocument を ParcelFileDescriptor に書き込みます。

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

画像の印刷

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

印刷サービスの構築

プリンタ 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_WIDTH と KEY_MAX_HEIGHT の 2 つのキーを MediaFormat に追加します。これらを MediaFormat に追加したら、configure() で MediaFormat を MediaCodec インスタンスに渡します。

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

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

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

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

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

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

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

サーフェスイメージリーダー

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

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

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

ピークと RMS の測定

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

ラウドネスエンハンサー

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

リモコン

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

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

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

リモコンからの評価

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

新しい Rating クラスは、ユーザーの評価に関する情報をカプセル化します。評価は、評価スタイル（RATING_HEART、RATING_THUMB_UP_DOWN、RATING_3_STARS、RATING_4_STARS、RATING_5_STARS、RATING_PERCENTAGE のいずれか）とそのスタイルに適した評価値によって定義されます。

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

setTransportControlFlags() に FLAG_KEY_MEDIA_RATING フラグを追加して、評価 UI をユーザーに公開するシグナル（該当する場合）。
editMetadata() を呼び出して RemoteControlClient.MetadataEditor を取得し、addEditableKey() で RATING_KEY_BY_USER を渡します。
次に、putObject() を呼び出し、キーとして RATING_KEY_BY_USER を、値として上記の評価スタイルのいずれかを渡して、評価スタイルを指定します。

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

字幕

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

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

動画コンテンツの表示に VideoView を使用しない場合は、ユーザーの字幕設定にできるだけ近い字幕オーバーレイを表示する必要があります。新しい CaptioningManager API を使用すると、CaptioningManager.CaptionStyle で定義されたスタイル（書体や色など）を含め、ユーザーの字幕設定をクエリできます。動画が開始した後にユーザーが設定を調整する場合は、CaptioningManager.CaptioningChangeListener のインスタンスを登録して設定変更をリッスンし、設定が変更されたときにコールバックを受け取るようにします。その後、必要に応じて字幕を更新します。

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

シーンとトランジション

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

2 つのシーン間を移動するには、通常、次の操作を行う必要があります。

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

ステップ 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 を使用して、一連の遷移をプログラムで定義することもできます。

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

詳細については、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"）を受け入れるインテントフィルタを含める必要があります。次に、次の 4 つの抽象メソッドを DocumentsProvider に実装する必要があります。

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() を呼び出して保存できるセンサーイベントの最大数を取得し、その値をアプリが各イベントに必要な速度で除算します。この計算を使用して、Service（SensorEventListener を実装する）を呼び出す AlarmManager でウェイクアラームを設定し、センサーをフラッシュします。

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

コントローラ ID

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

コネクテッドデバイスから提供されるプロダクト ID とベンダー ID は、getProductId() と getVendorId() からも入手できるようになりました。デバイスで使用可能なキーセットに基づいてキーマッピングを変更する必要がある場合は、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.TranslucentDecor と Theme.Holo.Light.NoActionBar.TranslucentDecor で、システムバーを半透明にできるようになりました。半透明のシステムバーを有効にすると、システムバーの背後の領域全体にレイアウトが表示されます。そのため、システムバーで覆われてはならない部分のレイアウトに対しても fitsSystemWindows を有効にする必要があります。

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

通知リスナーの強化

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

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

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

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

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

ユーザー補助サービスを提供するアプリは、AccessibilityNodeInfo.CollectionInfo と AccessibilityNodeInfo.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 差分レポートをご覧ください。