このページは 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 の変更によってアプリが影響を受ける可能性があることに注意してください。

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

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

アプリで WebView を使用している場合:

アプリの targetSdkVersion を「19」以上に更新した場合など、Android 4.4 で実行するとアプリの動作が異なる場合があります。

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 時間程度の範囲で実行されることがあります。

同期オペレーションに独自の Flex 間隔を指定するには、新しい 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 の実装を定義したら、PrintManager メソッド print() を使用して、ユーザーのリクエストに応じて印刷ジョブを実行できます。このメソッドは、PrintDocumentAdapter を引数の 1 つとして受け取ります。

画像の印刷

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

プリントサービスの構築

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

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

SMS プロバイダ

Telephony コンテンツプロバイダ（SMS プロバイダ）を使用すると、アプリはデバイス上の SMS メッセージと MMS メッセージを読み書きできます。受信、下書き、送信、保留中の SMS メッセージと MMS メッセージの表が含まれます。

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

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

詳しくは、SMS アプリを KitKat に対応させるをご覧ください。

ワイヤレスと接続

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

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

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

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

NFC リーダーモード

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

この新機能は、ホストカードエミュレーションと組み合わせることで、Android がモバイル決済インターフェースの両端で動作できるようにします。1 台のデバイスが決済端末として動作し（リーダーモードアクティビティを実行するデバイス）、もう 1 台のデバイスが決済クライアントとして動作します（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 への再生中に解像度をシームレスに変更できるようになりました。デコーダ入力フレームに新しい解像度をフィードでき、出力バッファの解像度を大きなギャップなしで変更できます。

アプリがコーデックに要求する最大解像度を指定する 2 つのキー（KEY_MAX_WIDTH と KEY_MAX_HEIGHT）を MediaFormat に追加することで、適応型再生を有効にできます。これらを MediaFormat に追加したら、configure() を使用して MediaFormat を MediaCodec インスタンスに渡します。

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

H.264 動画のデコード中に解像度を変更するには、MediaCodec.queueInputBuffer() を使用してフレームをキューに追加し続けますが、新しいシーケンスパラメータセット（SPS）と画像パラメータセット（PPS）の値を、即時デコーダ更新（IDR）フレームとともに 1 つのバッファに指定してください。

ただし、適応型再生用にコーデックを構成する前に、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）と、そのスタイルに適した評価値によって定義されます。

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

評価 UI をユーザーに公開することを示す（該当する場合）には、setTransportControlFlags() に FLAG_KEY_MEDIA_RATING フラグを追加します。
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 の個別の状態（「シーン」）を定義し、それぞれに個別のレイアウトを作成できることです。1 つのシーンから別のシーンにアニメーション化するには、「遷移」を実行します。これにより、現在のシーンから次のシーンにレイアウトを変更するために必要なアニメーションが計算されます。

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

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

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

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

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

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

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

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

Animator の一時停止

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 クラスに 2 つの新しいバージョンの registerListener() メソッドが追加され、「最大レポートレイテンシ」を指定できるようになりました。この新しいパラメータは、新しいセンサーイベントの配信で SensorEventListener が許容する最大遅延を指定します。たとえば、バッチレイテンシを 1 分に指定すると、システムは onSensorChanged() メソッドを連続して呼び出し（バッチ化されたイベントごとに 1 回）、最近のバッチ化されたイベントセットを 1 分以内の間隔で配信します。センサーイベントは最大レポートレイテンシの値より長く遅延されることはありませんが、他のアプリが同じセンサーに対してより短いレイテンシをリクエストしている場合は、より早く到着することがあります。

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

注: センサーイベントのバッチ処理はハードウェアセンサーのサポートを必要とするため、すべてのデバイスがサポートしているわけではありません。ただし、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.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 クラスで、新しいテキストコンテンツで動的に更新される UI の部分の「ライブ領域」を宣言できるようになりました。これは、新しい accessibilityLiveRegion 属性を XML レイアウトに追加するか、setAccessibilityLiveRegion() を呼び出すことで行います。たとえば、ログイン画面に「パスワードが正しくない」旨の通知を表示するテキストフィールドを含める場合、そのテキストフィールドをライブリージョンとしてマークする必要があります。これにより、スクリーンリーダーはメッセージが変更されたときにそのメッセージを読み上げます。

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

アプリの権限

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

INSTALL_SHORTCUT: ランチャーにショートカットをインストールすることをアプリに許可する
UNINSTALL_SHORTCUT: ランチャーでショートカットをアンインストールすることをアプリに許可する
TRANSMIT_IR: デバイスの赤外線送信機能（利用可能な場合）を使用することをアプリに許可します

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

デバイスの機能

以下に、<uses-feature> タグで宣言してアプリの要件を宣言し、Google Play でフィルタリングを有効にしたり、実行時に確認したりできる新しいデバイス機能を示します。

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

Android 4.4 のすべての API の変更の詳細については、API の相違点レポートをご覧ください。