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 差分レポートをご覧ください。