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()
メソッドを使用して、PdfDocument
を ParcelFileDescriptor
に書き込みます。
PrintDocumentAdapter
の実装を定義したら、PrintManager
メソッドの print()
を使用してユーザーのリクエストに応じて印刷ジョブを実行できます。このメソッドは引数の 1 つとして PrintDocumentAdapter
を受け取ります。
画像の印刷
写真などのビットマップだけを印刷する場合は、サポート ライブラリのヘルパー 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)の値を、Instantaneous Decoder Refresh(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
が提供されます。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_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()
メソッドを使用して、VideoView
に WebVTT 字幕トラックを指定することもできます。このメソッドは、字幕データを保持する InputStream
と、字幕データの形式(createSubtitleFormat()
を使用して指定できる)を指定する MediaFormat
オブジェクトを受け入れます。字幕は、ユーザーの好みに応じて動画上にも重ねて表示されます。
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
が使用されます。これにより、必要に応じてビューのフェード、移動、サイズ変更が自動的に行われます。さらに、これらのクラスを拡張して、お好みのアニメーションを実行することで、カスタム遷移を作成することもできます。カスタム遷移ではプロパティの変更をトラッキングし、その変更に基づいてアニメーションを作成できます。たとえば、ビューの「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()
を呼び出して保存できるセンサー イベントの最大数を取得し、その値をアプリが各イベントに必要なレートで割ります。この計算を使用して、Service
(SensorEventListener
を実装する)を呼び出してセンサーをフラッシュする 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.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 の違いレポートをご覧ください。