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

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 アプリの互換性に関する問題のトラッカーを使用してご報告ください。

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

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

アプリが、ピクチャー イン ピクチャー（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 shell コマンドを使用して、音声再生の動作をテストします。

変更のテスト

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）は、アプリがフォアグラウンドにある間に起動して、ユーザーが開始したオペレーションを延長する必要があります。特定のケースでは、アプリがバックグラウンドにあるときにフォアグラウンド サービスを起動できます。ただし、これらのフォアグラウンド サービスには通常、使用中の（WIU）機能は付与されません。

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

便利な参考資料を以下に示します。

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

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

影響を受けるオーディオ API の完全なリスト