強化背景音訊

從 Android 17 開始，音訊架構會對背景音訊互動強制執行限制，包括音訊播放、音訊焦點要求和音量變更 API，確保這些變更是由使用者刻意啟動。

在 Android 17 上執行的所有應用程式，如果具有這些背景音訊互動，則必須有可見的活動，或必須執行非 SHORT_SERVICE 類型的前景服務。無論應用程式是否指定 API 級別 37，都適用這項規定。

如果應用程式指定 Android 17 (API 級別 37)，則有額外限制。如果應用程式在背景執行，則必須執行具有使用期間 (WIU) 功能的前景服務。(如果前景服務是因應使用者啟動的操作而啟動，或是在應用程式向使用者顯示時啟動，則會獲得 WIU 功能)。不過，如果應用程式已取得精確鬧鐘權限，且正在變更具有 USAGE_ALARM 屬性的音訊串流，則不需具備 WIU 功能。

如果應用程式在無效的生命週期內嘗試呼叫音訊 API，音訊播放和音量變更 API 會自動失敗，不會擲回例外狀況或提供失敗訊息。音訊焦點 API 失敗，結果代碼為 AUDIOFOCUS_REQUEST_FAILED。

異動原因

導入這些限制的目的，是為了減少非預期的背景音訊錯誤。例如：

• 如果應用程式在沒有前景服務的情況下播放音訊，可能會遭到凍結。當應用程式最終解除凍結時，可能會在數小時後意外恢復音訊播放。
• 如果應用程式在沒有前景服務的情況下播放音訊，會受到各種執行限制，導致音訊播放不流暢。
• 播放作業與活動生命週期分離，可能導致播放工作階段或焦點事件外洩，且使用者無法停止播放。

我們鼓勵開發人員測試應用程式，並在行為變更對任何預期的音訊用途造成負面影響時提供意見回饋。如要回報任何問題，請使用 Android 17 應用程式相容性 Issue Tracker。

找出受影響的背景音訊用途

稽核音訊播放功能，確認應用程式是否要在特定情況下提供背景音訊互動功能。

如果應用程式只打算在顯示使用者可見的活動時播放音訊或使用音訊 API，包括使用子母畫面 (PiP) 模式，則不會受到任何異動影響。

如果應用程式提供 VOIP 功能 (包括視訊通話應用程式)，則必須符合播放功能相關規定 (通常是使用建議的電信 API)，才能成功錄製音訊，因此不太可能受到影響。

如果應用程式打算在螢幕關閉或活動未顯示時繼續播放音訊 (最常見於音樂串流應用程式或 Podcast 應用程式)，則視為提供背景音訊功能，必須符合新規定。

可能受到影響的背景音訊情境

如果應用程式未遵循在開啟時啟動音訊互動，或回應明確的使用者觸發條件，則應用程式的功能可能會遭到靜音。

舉例來說，如果應用程式為了回應 BOOT_COMPLETE 而啟動前景服務，並嘗試與音訊互動，系統就會抑制該服務。

降低背景音訊影響的最佳做法

• 使用 media3 Jetpack 程式庫的 MediaSessionService 元件，管理背景音訊播放。

  這樣一來，由於程式庫會協助管理播放生命週期，應用程式就不太可能受到背景強化措施的影響。

• 如果您未使用 media3 程式庫，則必須手動啟動 mediaPlayback FGS。如果可能發生背景音訊，請一律在應用程式位於前景時啟動前景服務。

  舉例來說，如果您的應用程式是影片串流應用程式，通常只在前景執行，但包含使用者功能，可在螢幕關閉時繼續播放，則當使用者啟動播放觸發條件時，應用程式仍應啟動前景服務。

  這樣可以確保前景服務啟動時具備 WIU 功能。

• 在 10 分鐘內的暫時性失敗期間，保持 mediaPlayback FGS 啟用。

  如果應用程式發生暫時性故障，例如因網路活動而導致緩衝處理問題，或發生預期的暫時中斷 (例如 AUDIOFOCUS_LOSS_TRANSIENT)，則應繼續播放。因此，FGS 應保持啟用狀態。

• 在播放結束時停止前景服務，並僅在使用者明確繼續播放時重新開始播放。

  如果收到永久結束播放的信號 (例如內容播放完畢且未啟用自動播放、AUDIOFOCUS_LOSS、UMO 傳送暫停事件，或媒體鍵事件)，或發生無法復原的錯誤，應用程式應停止音訊互動、停止前景服務，並結束媒體工作階段。完成上述所有步驟，即代表使用者已「完成」所需的背景音訊互動。完成後，應用程式就不再具備背景音訊互動功能。

  之後，如果使用者明確恢復播放 (例如透過應用程式 UI 或通用媒體物件播放按鈕)，系統應傳回啟動音訊播放的意圖，進而啟動新的 FGS。

• 使用 adb shell 指令測試音訊播放行為。

測試政策變更

如要測試應用程式是否符合規定，請在搭載 Android 17 以上版本 (Beta 3 起) 的應用程式上，執行下列 ADB 指令：

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

這個指令有下列選項：

• enable：為所有應用程式啟用所有音訊強化限制。無論應用程式是否指定 Android 17 (API 級別 37) 為目標，都必須遵守 WIU 前景服務規定。此外，即使應用程式正在變更鬧鐘串流，且具備精確鬧鐘權限，系統仍會強制執行這項規定。

• disable：停用所有音訊強化限制。

• throw：為所有應用程式啟用所有音訊強化限制，例如 enable。此外，這個旗標會啟用明顯失敗，針對音量和焦點互動擲回 IllegalStateException。如果是音訊播放，寫入方法會持續傳回錯誤代碼。如果播放模式沒有明確寫入，應用程式就會異常終止。

使用 adb dumpsys audio 或 logcat，判斷應用程式是否因音訊強化措施而發生無訊息失敗。如果成功，系統會顯示前置字元為 AudioHardening 的項目，並附上套件名稱。如果訊息包含 level: full，表示應用程式正在執行前景服務，但該服務不具備使用期間功能。如果訊息包含 level: partial，表示應用程式並未執行前景服務。

瞭解具備「使用期間」功能的 FGS

一般來說，前景服務 (FGS) 必須在應用程式處於前景時啟動，才能擴充使用者啟動的操作。在某些特定情況下，應用程式可以在背景執行時啟動前景服務。不過，這類前景服務通常不會獲得「使用期間」(WIU) 功能。

WIU 就像安全閘門，可防止從背景啟動的前景服務在使用者可能未察覺應用程式活動時，執行特定機密行為。這項功能可防止應用程式存取位置、相機或麥克風等機密資料，且自 Android 17 起，也會封鎖通常需要可見 UI 情境的音訊 API。

以下是實用參考資料：

• 標準前景服務：如果服務是在應用程式可見時啟動，或已獲授予背景活動啟動功能，則可取得 WIU 存取權。
• 背景啟動的 FGS (BFSL)：多數不授予 WIU 存取權。授予 WIU 的主要例外狀況，是涉及明確使用者意圖的互動，例如點擊通知、與小工具互動，或來自外部裝置的媒體按鍵事件。
• 系統啟動的 FGS：如果前景服務是由系統伺服器委派啟動 (例如透過 Telecom Jetpack 程式庫)，或由代表提升前景狀態的系統繫結啟動，以執行專屬功能 (例如 VoiceInteractionService)，則會獲得 WIU 存取權。

詳情請參閱「從背景啟動前景服務的限制」。

受影響的 Audio API 完整清單