Android 10 改善了需要同時進行多個活動音訊擷取的使用者體驗，例如，如果使用者想要使用輔助服務提供的語音命令控制 VoIP 通話或錄影機。
音訊框架實施的策略僅允許某些特權應用程式與常規應用程式同時擷取。
並發策略是透過使其捕獲的音訊靜音而不是阻止應用程式開始捕獲來實現的。這允許框架動態地解決主動捕獲用例的數量和類型的變化，而不會阻止應用程式在另一個應用程式完成捕獲後可以恢復對麥克風的完全存取權的情況下開始捕獲。
音訊 HAL 和音訊子系統的結果是它們必須同時支援多個活動輸入流，即使在某些情況下，只有一個流向活動用戶端提供非靜默音訊。
客戶盡職調查要求
有關並發捕獲支援的要求，請參閱CDD 。
從音頻 HAL 捕捉情況
並發擷取場景可能會導致活動輸入流數量、輸入裝置選擇或預處理配置方面的不同情況。
並發可能發生在下列各項之間：
- 來自應用處理器 (AP) 的多個輸入流
- 輸入串流和語音通話
- 輸入流和音頻 DSP 實現低功耗熱詞檢測
AP 輸入流的同時活動
音訊框架使用音訊策略設定檔audio_policy_configuration.xml來決定可以同時開啟和活動多少個輸入流。
音訊 HAL 至少必須支援開啟且活動的設定檔中列出的每個輸入設定檔（角色sink的mixPort ）的至少一個實例。
裝置選用
當多個活動用戶端連接到相同 HAL 輸入流時，框架會根據使用案例優先順序為此輸入流選擇適當的裝置。
當多個輸入流處於活動狀態時，每個流可以有不同的設備選擇。
如果技術相容，建議音訊 HAL 和子系統允許從不同裝置捕捉不同的串流，例如藍牙耳機和內建麥克風。
如果存在不相容性（例如兩個裝置共用相同的數位音訊介面或後端），音訊 HAL 必須選擇哪個串流控制裝置選擇。
在這種情況下：
- 當重複相同的場景時，結果狀態必須一致並提供相同的設備選擇。
- 當並發狀態結束時，剩餘的活動流必須路由到該流上最初請求的設備。
如果活動案例之間的音訊 HAL 定義了優先順序，請遵循frameworks/av/services/audiopolicy/common/include/policy.h中的source_priority()中的相同順序
預處理選擇
音訊框架可以使用addEffect()或removeEffect() HAL 方法請求對輸入流進行預處理。
對於給定輸入流的預處理，音訊框架僅啟用與輸入流上最高優先級活動用例相對應的配置。但是，在使用案例啟動和停用期間可能存在一些重疊，導致兩個同時活動的進程（例如，迴聲消除器的兩個實例）在同一輸入流上運行。在這種情況下，HAL 實作選擇接受哪個請求；它會追蹤活動請求並在任一進程被停用時恢復正確的狀態。
當多個捕獲流同時處於活動狀態時，可能會在不同的流上執行不同的預處理請求。
HAL 和音訊子系統實作應該允許將不同的預處理應用於不同的串流，即使它們共用相同的輸入裝置。也就是說，應該在對來自主捕獲源的流進行解復用之後應用預處理。
如果由於技術原因在給定音頻子系統上不可能，則音頻 HAL 應應用類似於設備選擇中列出的優先級規則。
從 AP 進行並發語音通話和捕獲
當語音通話處於活動狀態時，可能會從 AP 擷取。這種情況在 Android 10 中並不新鮮，並且與並發捕獲功能沒有直接關係，但提及此場景的指南很有用。
呼叫期間需要從 AP 進行兩種不同類型的擷取。
捕獲呼叫 RX 和 TX
捕獲呼叫 RX 和 TX 是透過使用音訊來源AudioSource.VOICE_UPLINK或AudioSource.VOICE_DOWNLINK和/或設備AudioDevice.IN_TELEPHONY_RX觸發的。
音訊 HAL 應在輸入設定檔（角色sink的mixPort ）上公開，並具有來自設備AudioDevice.IN_TELEPHONY_RX的可用路由。
連線呼叫時（音訊模式為AudioMode.IN_CALL ），應該可以從裝置AudioDevice.IN_TELEPHONY_RX取得至少一個活動擷取流。
通話時從輸入裝置捕獲
當呼叫處於活動狀態時（音訊模式為AudioMode.IN_CALL ），應該可以開啟並啟動來自 AP 的輸入流，如AP 輸入流的並發活動部分所指定。
然而，設備選擇和預處理的優先順序應始終由語音通話驅動，以防與 AP 輸入流的請求發生衝突。
DSP 和 AP 並發捕獲
當音訊子系統包含支援低功耗音訊上下文或熱詞偵測功能的 DSP 時，實施方案應支援從 AP 和音訊 DSP 進行並發擷取。這包括 DSP 在初始檢測階段進行的捕獲以及在 DSP 觸發檢測後由 AP 使用AudioSource.HOTWORD進行的捕獲。
這應該透過聲音觸發器 HAL 透過實現描述符報告的並發捕獲標誌來反映： ISoundTriggerHw.Properties.concurrentCapture = true 。
音訊 HAL 也應該公開並輸入特定於由標誌AudioInputFlag.HW_HOTWORD標識的熱詞捕獲的設定檔。此實作應支援開啟和啟動此設定檔上的多個串流，該數量至少等於聲音觸發器 HAL 可以同時載入的聲音模型的數量。
當其他輸入設定檔處於活動狀態時，應該可以從此輸入設定檔進行擷取。
對 Assistant 實施的影響
數據使用和用戶通知要求
由於並發麥克風使用如果被濫用可能會洩露用戶私人數據，因此我們需要將以下條件和保證應用於要求擔任助理角色的特權預加載應用程式。
- 除非使用者與助理交互，否則透過麥克風收集的資料不應離開裝置。例如，觸發熱詞後。
- 同時偵聽的應用程式應在偵測到熱詞後向使用者提供視覺提示。這有助於用戶了解進一步的對話將透過不同的應用程式（例如助手）進行。
- 用戶應該能夠關閉麥克風或助手觸發器。
- 當錄音被儲存時，使用者應該能夠隨時存取、檢視和刪除錄音。
Android 10 的功能改進
助手之間不互相遮擋
在 Android 9 或更低版本上，當裝置上有兩個始終在線的助理時，只有其中一個可以監聽其熱詞。因此，需要在兩個助理之間進行切換。在 Android 10 中，預設助手可以與其他助手同時監聽。這將為同時使用兩位助手的使用者帶來更流暢的體驗。
應用程式保持麥克風打開
當 Shazam 或 Waze 等應用程式將麥克風保持開啟時，預設的助手仍然可以監聽熱詞。
對於非預設的 Assistant 應用，Android 10 的行為沒有改變。
音頻 HAL 實現範例
符合本文檔中指南的音訊 HAL 實作範例可以在AOSP中找到。