バックグラウンド音声の強化

Android 17 以降、オーディオ フレームワークは、バックグラウンド オーディオ インタラクション（オーディオ再生、オーディオ フォーカス リクエスト、音量変更 API など）に制限を適用し、これらの変更がユーザーによって意図的に開始されるようにします。

Android 17 で動作し、これらのバックグラウンド音声インタラクションを行うすべてのアプリは、表示されるアクティビティがあるか、SHORT_SERVICE タイプ以外のフォアグラウンド サービスを実行している必要があります。これは、アプリが対象 API レベル 37 をターゲットとしているかどうかに関係なく適用されます。

Android 17（API レベル 37）をターゲットとするアプリには、追加の制限があります。アプリがバックグラウンドで実行されている場合、アプリは使用中（WIU）機能を備えたフォアグラウンド サービスを実行している必要があります。（フォアグラウンド サービスは、ユーザーが開始した操作に応じて開始された場合、またはアプリがユーザーに表示されている間に開始された場合に、WIU 機能が付与されます）。ただし、アプリに正確なアラーム権限が付与されており、USAGE_ALARM 属性を持つ音声ストリームに変更を加えている場合、WIU 機能の要件は免除されます。

アプリが有効なライフサイクルにないときにオーディオ API を呼び出そうとすると、オーディオ再生 API と音量変更 API は例外をスローしたり、失敗メッセージを提供したりすることなく、サイレントに失敗します。オーディオ フォーカス API が失敗し、結果コード AUDIOFOCUS_REQUEST_FAILED が返されます。

今回の変更を実施する理由

これらの制限を導入する目的は、意図しないバックグラウンド オーディオのバグを減らすことです。以下にいくつか例を示します。

• フォアグラウンド サービスなしで音声を再生しているアプリは、フリーズする可能性があります。アプリが最終的にフリーズ解除されると、予期せず音声再生が再開されます。これは数時間後になる可能性があります。
• フォアグラウンド サービスなしでオーディオを再生するアプリは、さまざまな実行制限に直面し、オーディオ パフォーマンスが不安定になります。
• 再生がアクティビティのライフサイクルから切り離され、再生セッションやフォーカス イベントがリークし、ユーザーが再生を停止できなくなる可能性があります。

デベロッパーの皆様には、アプリをテストし、意図的な音声のユースケースに悪影響を及ぼす動作変更がある場合は、フィードバックをお寄せいただくことをおすすめします。問題がある場合は、こちらの Android 17 アプリ互換性 Issue Tracker を使用して報告してください。

影響を受けるバックグラウンド音声のユースケースを特定する

音声再生の実装を監査し、条件付きの状況でもアプリがバックグラウンド音声操作機能を提供することを意図しているかどうかを特定します。

アプリが、ピクチャー イン ピクチャー（PiP）モードの使用など、ユーザーに表示されるアクティビティを表示している間にのみ、音声の再生や音声 API の利用を目的としている場合、これらの変更による影響はありません。

ビデオ通話アプリなど、VOIP 機能を提供するアプリは、音声を正常に録音するために、再生用に導入される要件をすでに満たしている必要があります（通常は、推奨される Telecom API を利用します）。そのため、影響を受ける可能性は低いです。

画面がオフになっている間やアクティビティが表示されていない間にアプリが音声再生を継続することを意図している場合（音楽ストリーミング アプリやポッドキャスト アプリでよく見られます）、アプリはバックグラウンド音声機能を提供しているとみなされ、新しい要件を満たす必要があります。

影響を受ける可能性が高いバックグラウンド オーディオのシナリオ

アプリが、アプリが開いている間に開始された音声操作を継続するモデルに準拠していない場合、または明示的なユーザー トリガーに応答する場合、アプリの機能がサイレント モードで抑制される可能性があります。

たとえば、アプリが BOOT_COMPLETE に応じてフォアグラウンド サービスを開始し、音声とやり取りしようとすると、抑制されます。

影響を軽減するためのバックグラウンド音声のベスト プラクティス

• media3 Jetpack ライブラリの MediaSessionService コンポーネントを使用して、バックグラウンドでの音声再生を管理します。

  そうすれば、ライブラリが再生ライフサイクルの管理を支援するため、アプリがバックグラウンドの強化による影響を受ける可能性は低くなります。

• media3 ライブラリを使用していない場合は、mediaPlayback FGS を手動で開始する必要があります。バックグラウンド音声が発生する可能性がある場合は、アプリがフォアグラウンドにあるときに必ずフォアグラウンド サービスを開始します。

  たとえば、アプリが動画ストリーミング アプリで、通常はフォアグラウンドのみだが、画面がオフのときも再生を続けるユーザー アフォーダンスが含まれている場合、ユーザーが開始した再生トリガーが発生したときに、アプリはフォアグラウンド サービスを開始する必要があります。

  これにより、フォアグラウンド サービスが WIU 機能で開始されます。

• 10 分未満の一時的な障害の間、mediaPlayback FGS をアクティブな状態に保ちます。

  ネットワーク アクティビティによるバッファリングの問題など、アプリに一時的な障害が発生した場合や、AUDIOFOCUS_LOSS_TRANSIENT などの想定される一時的な中断が発生した場合でも、再生のインテントは継続する必要があります。そのため、FGS はアクティブなままにする必要があります。

• 再生の終了時にフォアグラウンド サービスを停止し、ユーザーが明示的に再生を再開した場合にのみ再生を再開します。

  再生を終了する永続的なシグナル（たとえば、自動再生なしでコンテンツが完了した場合、AUDIOFOCUS_LOSS、UMO からの一時停止イベント、メディアキー イベントなど）または回復不能な障害が発生した場合、アプリはオーディオ インタラクションを停止し、フォアグラウンド サービスを停止して、メディア セッションを終了する必要があります。これらすべてを行うことは、ユーザーが望むバックグラウンド音声操作を「終了」するというユーザーの概念に対応します。この操作を行うと、アプリはバックグラウンド音声操作機能を使用できなくなります。

  その後、ユーザーがアプリの UI や Universal Media Object の再生ボタンなどを使用して明示的に再生を再開すると、音声再生を開始するインテントが返され、FGS が新たに開始されます。

• adb シェルコマンドを使用して、オーディオ再生の動作をテストします。

変更のテスト

Android 17 以降（ベータ版 3 以降）を搭載したアプリでアプリのコンプライアンスをテストするには、次の ADB コマンドを実行します。

adb shell cmd audio set-enable-hardening <enable|disable|throw>

このコマンドには次のオプションがあります。

• enable: すべてのアプリに対して、すべての音声強化制限を有効にします。WIU フォアグラウンド サービスの要件は、アプリが Android 17（API レベル 37）をターゲットとしているかどうかにかかわらず適用されます。また、アプリがアラーム ストリームに変更を加えており、正確なアラームの権限を持っている場合でも、この要件は適用されます。

• disable: すべての音声強化制限を無効にします。

• throw: enable など、すべてのアプリですべてのオーディオ強化制限を有効にします。また、このフラグを有効にすると、音量とフォーカスの操作で IllegalStateException がスローされ、エラーが明確に示されます。音声再生の場合、書き込みメソッドはエラーコードを永続的に返します。明示的な書き込みのない再生モードの場合、アプリはクラッシュします。

adb dumpsys audio または logcat を使用して、オーディオの強化によりアプリでサイレント障害が発生したかどうかを特定します。その場合、パッケージ名に AudioHardening という接頭辞が付いたエントリが表示されます。メッセージに level: full が含まれている場合、アプリはフォアグラウンド サービスを実行していますが、サービスに使用中の機能がありません。メッセージに level: partial が含まれている場合、アプリはフォアグラウンド サービスをまったく実行していません。

使用中機能を持つ FGS について

一般に、フォアグラウンド サービス（FGS）は、ユーザーが開始したオペレーションを拡張するために、アプリがフォアグラウンドにあるときに起動する必要があります。特定のケースでは、アプリがバックグラウンドで動作しているときにフォアグラウンド サービスを起動することが許可されます。ただし、これらのフォアグラウンド サービスには通常、While-In-Use（WIU）機能は付与されません。

WIU はセキュリティ ゲートとして機能します。ユーザーがアプリのアクティビティを認識していない可能性がある場合に、バックグラウンドから開始された FGS が特定の機密性の高い動作に関与するのを防ぎます。アプリが位置情報、カメラ、マイクなどの機密データにアクセスするのを防ぎます。また、Android 17 以降では、通常は表示される UI コンテキストを必要とするオーディオ API もブロックします。

以下に、便利なリファレンスを示します。

• 標準 FGS: アプリが表示されている間、またはバックグラウンド アクティビティの起動機能が付与されている間に開始されたサービスには、WIU アクセスが付与されます。
• バックグラウンドで開始された FGS（BFSL）: ほとんどの場合、WIU アクセスは付与されません。WIU を付与する主な例外は、明示的なユーザー インテントを伴うインタラクションです。たとえば、通知のクリック、ウィジェットの操作、外部デバイスからのメディアキー イベントなどです。
• システムが開始した FGS: フォアグラウンド サービスは、システム サーバーの委任（Telecom Jetpack ライブラリなど）によって開始された場合、または専用の機能を実行するために昇格されたフォアグラウンド状態を表すシステム バインディング（VoiceInteractionService など）によって開始された場合に、WIU アクセス権が付与されます。

詳しくは、バックグラウンドからフォアグラウンド サービスを開始する場合の制限をご覧ください。

影響を受ける Audio API の全リスト