連載

2015年6月23日

細か過ぎて伝わってないけど開発者が知っておきたいAndroid Mの新機能まとめ：Androidで動く携帯Javaアプリ作成入門（58）（6/6 ページ）

Google I/O 2015で発表された次期版Android M。Google Now on tapで使うアシストAPIや、App Links、App Permissions、省電力のDoze／App Stanby、決済機能Android Payなどで使う指紋認証機能など新機能を分類して紹介。

[緒方聡，＠IT] PC用表示関連情報

LINE

Hatena

前のページへ | 　　　　　　

カメラ機能の変更点

　Android Mではカメラのフラッシュとカメラ画像再処理のために以下の新しいAPIが追加されます。

フラッシュAPI

　カメラがフラッシュ装置を持っている場合は、CameraManager.setTorchMode()によりカメラデバイスを開くことなくストロボのトーチモードのオン／オフ切り替えを呼び出せます。アプリはフラッシュ装置やカメラデバイスの排他的な所有権を持っていません。他のアプリからsetTorchMode()が呼び出されトーチモードがオフにされることがあります。トーチモードがオンのままアプリが終了した場合、トーチモードはオフになります。

　CameraManager.registerTorchCallback()でトーチモードの状態が通知されるコールバックを登録できます。コールバックが登録されると、すぐにフラッシュユニットを持つ全てのカメラデバイスの現在のトーチモードの状態が通知されます。トーチモードのオン／オフ切り替えに成功すると、CameraManager.TorchCallback.onTorchModeChanged()がコールバックされます。

画像再処理API

　Android 5.0で追加されたCamera2 APIは、YUV（※）データと画像の再処理をサポートするようになります。

※輝度・青色との差・赤色との差という3色の組み合わせで表現される色空間で、主にTV放送やDVD映像向け

　アプリはCameraCharacteristics.REQUEST_AVAILABLE_CAPABILITIESにより再処理能力があるかどうかを検出します。もしデバイスが再処理をサポートするなら、再処理可能なカメラキャプチャセッションをCameraDevice.createReprocessableCaptureSession()により作成し、再処理入力バッファーのためのリクエストを作成します。

　ImageWriterを使用し、入力バッファーフローからカメラ再処理入力に接続します。空のバッファーを取得するプログラミングモデルは次の通りです。

ImageWriter.dequeueInputImage()を呼び出す
入力バッファーにデータを入力する
ImageWriter.queueInputImage()を呼び出しカメラにバッファーを送る

　もしImageWriterをandroid.graphics.ImageFormat.PRIVATEイメージと一緒に使用しているなら、アプリは直接画像データにアクセスできません。その代わり、ImageWriter.queueInputImage()を呼び出すことにより任意のバッファーを作成することなくImageFormat.PRIVATEイメージをImageWriterに直接渡せます。

　ImageReaderはandroid.graphics.ImageFormat.PRIVATE形式の画像ストリームをサポートするようになりました。このサポートは、アプリがImageReader出力イメージの円形イメージキューを利用することが可能になり、一つまたは複数のイメージを選択し、カメラ再処理のためにImageWriterに送信します。

カメラサービスの変更

　Android Mでは、カメラサービスからの共有リソースへのアクセスモデルがプライオリティの高いプロセスを優先する方式に変更されました。

　カメラサブシステムへのアクセスは呼び出し元のアプリプロセスの優先度に基づいて付与されます。ユーザーに表示されているフォアグラウンドアクティビティのアプリプロセスは、一般的にカメラリソース取得を行う最も高い優先順位を与えられます。優先度の高いアプリがカメラを使用しようとして、優先度の低いアプリがカメラから「追い出される」ことがあります。非推奨のカメラAPIでは、このケースではonError()が呼び出されます。Camera2 APIではonDisconnected()が呼び出されます。

　適切なカメラハードウエアを備えたデバイスでは、別々のアプリプロセスから独立して同時に異なるカメラを使えます。しかし、同時アクセスすることでパフォーマンスやカメラ機能の大幅な性能低下が引き起こされる場合、マルチプロセスユースはカメラサービスによって許可されません。つまり、優先度の低いアプリは、優先度の高いアプリのために、たとえ使用するカメラが異なる場合でも「立ち退き」させられることがあります。

オーディオ機能の変更点

　Android Mはオーディオ処理において以下の機能強化が図られています。

AudioManagerの変更

　AudioManagerによるボリュームの変更やミュート化はサポートされなくなりました。setStreamSolo()は非推奨になり、代わりにAudioManager.requestAudioFocus()が用意されました。同様にsetStreamMute()も非推奨になり、AudioManager.adjustStreamVolume()、ADJUST_MUTE、ADJUST_UNMUTEが用意されました。

新しいAPI「android.media.midi」でMIDIがサポート

　このAPIを用いてMIDIイベントを送受信できます。

android.media.AudioRecord.Builderとandroid.media.AudioTrack.Builderの追加

　デジタルオーディオキャプチャとプレーバックオブジェクトを作成し、オーディオソースとシンクプロパティを、システムデフォルトをオーバーライドして設定します。

オーディオと入力デバイスを結び付けるAPIフック

　これは、とりわけゲームコントローラーからの音声検索やAndroid TVのリモコン接続などをアプリで利用する際に便利です。

　システムはユーザーが検索を開始した際にandroid.app.Activity.onSearchRequested()をコールバックします。コールバックでInputDeviceを受け取り、新しいInputDevice.hasMic()を呼び出してユーザーの入力デバイスが組み込みのマイクを持つかどうかを判定します。

android.media.AudioDevicesManagerの追加

　全ての添付されたオーディオソースをリストにし、オーディオデバイスを同期できます。オーディオデバイスが接続または切断されたことをアプリで検知したい場合、android.media.OnAudioDeviceConnectionListenerを利用することもできます。

動画処理の変更点

　Android Mでは以下の動画処理APIが追加されました。

android.media.MediaSync
オーディオとビデオストリームの同期をサポート。オーディオバッファーはノンブロッキング方式の場合、コールバックで返される。また、動的な再生速度をサポートする
MediaDrm.EVENT_SESSION_RECLAIMEDイベント
アプリによって開かれたセッションがリソースマネジャーによって回収されたことを示す。アプリがDRMセッションを使用している場合、このイベントを処理し、セッションを再利用しないように確認する必要がある
MediaCodec.CodecException.ERROR_RECLAIMEDエラーコード
リソースマネジャーがコーデックで使用されるメディアリソースを再利用することを示す。この例外でコーデックはリリースされ、終了状態に移行しなければならない
MediaCodecInfo.CodecCapabilities.getMaxSupportedInstances()
サポートされる同時コーデックインスタンス最大数のためのヒントを取得する
新しいMediaPlayer.setPlaybackParams()
ファーストモーションまたはスローモーション再生のためのメディア再生速度を設定する。また、動画に合わせた自動的なオーディオプレーバックのストレッチやスピードアップを行う

今後の連載でAndroid Mの新機能の使い方を詳細に解説

　今回は、Android M開発者プレビューの新機能をまとめて紹介しましたが、いかがでしたでしょうか。今後の連載でAndroid Mの新機能の使い方を詳細に解説する予定ですので、ご期待ください。