音訊焦點

應用程式會要求使用相同類型的音訊焦點，再啟動邏輯串流 和音訊屬性使用相同的音訊屬性。應用程式必須尊重焦點 造成的損失。

雖然我們建議傳送焦點要求，但系統不會強制執行此要求。 因此，請考慮將重心視為間接控制及避免衝突的方法 而非主要音訊控制機制車輛 不應仰賴專注系統運作音訊子系統。

聚焦互動

為了支援 AAOS，音訊焦點要求將根據預先定義的選項處理 要求的 CarAudioContext 與目前工作階段之間的互動 焦點物件互動方式分為三種類型：

• 獨家
• 拒絕
• 並行

不重複互動

這是 Android 最常採用的互動模型。

在專屬互動中，一次只能有一個應用程式保持專注。 因此，當現有焦點同時接受傳入的焦點要求 因此未聚焦於由於這兩個應用程式都能播放媒體，因此只能有一個應用程式可保留媒體 重點。因此，新啟動應用程式的焦點要求會傳回 AUDIOFOCUS_REQUEST_GRANTED，但目前播放音樂的應用程式收到 焦點變更事件，其中有與要求類型對應的遺失狀態 以及模型建立過程

拒絕互動

使用 reject (拒絕) 互動時，一律會拒絕傳入要求。適用對象 例如在通話進行中播放音樂時。在本 ，如果「撥號」應用程式為通話保留音訊焦點，而另一個應用程式要求焦點 播放音樂，音樂應用程式回應後會收到 AUDIOFOCUS_REQUEST_FAILED 加到要求中拒絕聚焦要求，因此不會分派任何焦點遺失 移到目前的焦點持有者

同時互動

AAOS 專屬於「並行」互動。這麼做可讓應用程式要求播放音訊 可專心看向其他應用程式。換 必須符合下列條件，才能同時進行並行互動。：

• 必須請求系統接收焦點要求 AudioManager.AUDIOFOCUS_GAIN_TRANSIENT_MAY_DUCK

• 目前的焦點持有者無法 setPauseWhenDucked(true)

• 目前的焦點持有者選擇不接收 Duck 事件

如果符合這些條件，焦點要求會傳回 AUDIOFOCUS_REQUEST_GRANTED，但目前的焦點擁有者在 重點。不過，如果目前的焦點持有者選擇接收 Duck 事件，或 按下時暫停，目前的焦點容器就會失去焦點，例如 獨家互動。

處理並行串流

雖然並行互動有許多用途，但您在混合與 單一輸出裝置的硬體層級。我們強烈建議您 允許同時播放的 CarAudioContext 應轉送至 不同的輸出裝置

透過針對並行串流使用不同的輸出裝置，即可啟用 HAL 混合其中一個串流，再混合它們，或轉送實體串流 與車內不同的喇叭配對如果邏輯串流混合 Android 的收益維持不變，並且會在同一實體串流中傳送。

例如，當同時提交導航和媒體時，其增益 都可以暫時縮小 (或隱藏) 更清楚地聽到導航指示。或者，使用導覽按鈕 媒體可能會轉送至駕駛端的揚聲器，而媒體會繼續 在整個木屋的其他位置繼續播放

互動矩陣

下表顯示由 CarAudioService 定義的互動矩陣。 每一列都代表目前焦點持有人的 CarAudioContext，而 欄代表傳入要求的值。

舉例來說，如果音樂媒體應用程式將焦點移至導航應用程式要求 矩陣表示這兩種互動可同時播放 並假設其他條件 並行互動則會完成

由於並行互動是並行互動，因此可能會有多個 。在此情況下，系統會將傳入的焦點要求與 目前的焦點擁有者，再決定要套用的互動。在本 個案最保守的互動勝出。拒絕公開授權，以及 最終並行

圖 1. 音訊焦點互動矩陣。

通話時導航

在 Android 11 中，我們推出了新的使用者設定，方便使用者 導航和通話之間的互動行為。設定之後 android.car.KEY_AUDIO_FOCUS_NAVIGATION_REJECTED_DURING_CALL 會變更 與傳入 NAVIGATION 焦點要求與目前CALL的互動 將焦點容器從並行變更為拒絕。如果使用者偏好 導航指示如何中斷通話，他們可以啟用這項設定。這個 會保留給使用者，並可動態設定，使後續焦點 要求會採用新的設定

可延遲的音訊焦點

在 Android 11 中，AAOS 新增了要求可延遲音訊焦點的支援。這個 可在與應用程式互動時，將非暫時的焦點要求延後 目前的焦點容器通常會使這些容器遭到拒絕。我們 焦點變更會導致延遲要求取得焦點 系統就會核准要求

延遲音訊焦點要求的規則

• 僅限非暫時性要求。只有在 並非暫時性的源頭，以免音訊長時間播放 以後的內容

• 一次只能延遲一項要求。如果可延遲的要求 在已延遲處理要求的情況下，原始的延遲要求 收到 AUDIOFOCUS_LOSS 變更事件，而新的要求收到 AUDIOFOCUS_REQUEST_DELAYED 的同步回應。

• 可延遲的要求必須具備 OnAudioFocusChangeListener 且 就會使用監聽器，在發生延遲情況時 要求最終獲準 (AUDIOFOCUS_GAIN)，或之後遭拒 (AUDIOFOCUS_LOSS)。

要求可延遲焦點

如要建構可延遲的要求：

1. 使用 AudioFocusRequest.Builder#setAcceptsDelayedFocusGain。

   mMediaWithDelayedFocusListener = new MediaWithDelayedFocusListener();
   
   mDelayedFocusRequest = new AudioFocusRequest
        .Builder(AudioManager.AUDIOFOCUS_GAIN)
        .setAudioAttributes(mMusicAudioAttrib)
        .setOnAudioFocusChangeListener(mMediaWithDelayedFocusListener)
        .setForceDucking(false)
        .setWillPauseWhenDucked(false)
        .setAcceptsDelayedFocusGain(true)
        .build();
   

2. 發出要求時，請處理 AUDIOFOCUS_REQUEST_DELAYED 回應：

   int delayedFocusRequestResults = mAudioManager.requestAudioFocus(mDelayedFocusRequest);
   if (delayedFocusRequestResults == AudioManager.AUDIOFOCUS_REQUEST_GRANTED) {
       // start audio playback
       return;
   }
   if (delayedFocusRequestResults == AudioManager.AUDIOFOCUS_REQUEST_DELAYED) {
        // audio playback delayed to audio focus listener
        return;
   }
   

3. 當要求延遲時，焦點事件監聽器會處理焦點上的變更：

   private final class MediaWithDelayedFocusListener implements
   OnAudioFocusChangeListener {
          @Override
          public void onAudioFocusChange(int focusChange) {
              synchronized (mLock) {
                  switch (focusChange) {
                      case AudioManager.AUDIOFOCUS_GAIN:
                          … // Start focus playback
                      case AudioManager.AUDIOFOCUS_LOSS_TRANSIENT:
                          … // Pause media transiently
                      case AudioManager.AUDIOFOCUS_LOSS:
                          … // Stop media
   

多可用區聚焦管理

如果車輛有多個音訊區，則會單獨管理音訊焦點 每個可用區因此，對某個可用區發出的要求不會考量 其他可用區的焦點，也不會導致其他可用區的焦點持有者 就會變得失焦如此一來，就能單獨管理主要車櫃的焦點 後座的娛樂系統，不會中斷 之間的變更

CarAudioService 會自動管理所有應用程式的焦點。重點 要求的音訊區域取決於相關聯的 UserId 或 UID (詳情請參閱音訊轉送)。

並行要求多個可用區的音訊

如果應用程式想要同時播放多個可用區的音訊，則必須要求 在每個可用區中加入 AUDIOFOCUS_EXTRA_REQUEST_ZONE_ID 套裝組合：

//Create attribute with bundle and AUDIOFOCUS_EXTRA_REQUEST_ZONE_ID
Bundle bundle = new Bundle();
bundle.putInt(CarAudioManager.AUDIOFOCUS_EXTRA_REQUEST_ZONE_ID,
               zoneId);

AudioAttributes attributesWithZone = new AudioAttributes.Builder()
     .setUsage(AudioAttributes.USAGE_MEDIA)
     .addBundle(bundle)
     .build();

//Create focus request using built attributesWithZone

這個 bundle 參數可讓要求者覆寫自動音訊區域 改為使用指定區域 ID。因此，應用程式 不同音訊區域的要求

HAL 音訊焦點

從 Android 11 開始，HAL 可以代表 以及外部串流雖然非必要，但我們強烈建議您使用這些 API 讓外界聲音成為 Android 生態系統中的最佳參與者，並且 以提供流暢的使用者體驗

HAL 是決定哪些聲音應優先處理的最終決定。 在這個範圍內，只要播放緊急與安全重要聲響 HAL 是否獲得音訊焦點，並且應繼續 即使 HAL 失去音訊焦點，仍會按適當方式播放。使用者 配合政府法規要求的聲音。

HAL 應在播放時主動將 Android 串流靜音 確保緊急聲響或安全重要聲響

音訊控制@2.0

AudioControl HAL 2.0 版引進了下列新的 API：

API	目的
IAudioControl#registerFocusListener	使用下列指令，註冊 IFocusListener 的例項： 音訊控制 HAL。這個事件監聽器可讓 HAL 要求並捨棄音訊 重點。HAl 會提供 ICloseHandle 執行個體， Android 即可取消註冊事件監聽器。
IAudioControl#onAudioFocusChange	向 HAL 通知狀態變更，以便得知 HAL 發出的焦點要求 使用 IFocusListener，包括對初始回應 焦點要求
IFocusListener#requestAudioFocus	代表 HAL 的指定用量、可用區 ID、 以及集中式增加類型
IFocusListener#abandonAudioFocus	針對指定的用量和可用區捨棄現有的 HAL 焦點要求 ID。

HAL 可以同時提出多個焦點要求，但僅限一項 每個用量和可用區 ID 配對的要求Android 會立即假設 HAL 一旦提出要求後，就會開始播放該使用量的音效 直到失去焦點

除了 registerFocusListener 以外，這些要求是 oneway，以確保 處理焦點要求時，Android 不會延遲 HAL。HAL 應該 不要等到取得專注時，才播放安全重要的音效。可以選填這個欄位 HAL 可讓 HAL 監聽及回應音訊焦點的變化 IAudioControl#onAudioFocusChange。

原始設備製造商 (OEM) 汽車語音焦點服務

在 Android 14 中，AAOS 導入車輛原始設備製造商 (OEM) 外掛程式服務，以便啟用 設定。適用對象 Car Audio 外掛程式服務，外掛程式 服務可讓原始設備製造商 (OEM) 管理車輛音訊攔截的對焦要求 課程中也會快速介紹 Memorystore 這是 Google Cloud 的全代管 Redis 服務因此，原始設備製造商 (OEM) 在管理焦點方面，能視需要更有彈性地管理焦點 依規章和法規限制因此，音訊焦點的互動方式可能會有差異 以及各區域的差異音訊焦點的基本前提 應用程式仍應要求聚焦，以提供更好的管理音訊 以提升使用者體驗一般來說，音訊廣告必須遵守特定規則 應用程式焦點要求：

• 應用程式若沒有高優先順序的高優先順序音訊焦點 (包括電話、 緊急警報或安全通知) 應用程式應該要能接收音訊 暫時或永久聚焦

• 啟用媒體焦點時：

  • 要求通話使用焦點的應用程式應可接聽來電 一起處理

  • 要求導航使用焦點的應用程式應能接收導航 您可以選擇同時對 並行或獨佔焦點

  • 如果應用程式要求使用 Google 助理做為使用焦點，應能取得使用焦點 兩者並行或完全不同

• 站在高優先順序的語音焦點 (包括來電、 緊急警報或安全通知) 應用程式已啟用、任何傳入 請視需要核准或延遲音訊焦點要求。

以上建議尚未涵蓋所有情況，但有助於應用程式協助要求 可以取得專注力。即使在高溫時也能 優先音效已啟用，仍必須遵守延遲焦點要求 且在高優先順序的音效停止時，應能集中註意力