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 應使用來自設備AudioDevice.IN_TELEPHONY_RX的可用路由在輸入配置文件（角色接收sink的mixPort ）上公開。
連接呼叫時（音頻模式為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 可以同時加載的聲音模型的數量。
當其他輸入配置文件處於活動狀態時，應該可以從該輸入配置文件進行捕獲。
對 Google 助理實施的影響
數據使用和用戶通知要求
因為並發麥克風使用，如果被濫用，可能會洩露用戶的私人數據，我們需要以下條件和保證適用於要求擔任助理角色的特權預加載應用程序。
- 除非用戶正在與 Google 助理交互，否則通過麥克風收集的數據不應離開設備。例如，觸發熱詞後。
- 並發偵聽的應用程序應在檢測到啟動指令後向用戶提供視覺提示。這有助於用戶了解進一步的對話將通過不同的應用程序，例如助手。
- 用戶應該能夠關閉麥克風或助手觸發器。
- 存儲錄音時，用戶應該能夠隨時訪問、查看和刪除錄音。
Android 10 的功能改進
助手不會互相屏蔽
在 Android 9 或更低版本上，當設備上有兩個始終在線的助手時，其中只有一個可能正在收聽其啟動指令。因此，需要在兩個助手之間進行切換。在 Android 10 中，默認助手可以與其他助手同時收聽。這為擁有兩個助手的用戶帶來了更加流暢的體驗。
保持麥克風打開的應用程序
當 Shazam 或 Waze 等應用程序保持麥克風打開時，默認的智能助理仍然可以收聽啟動指令。
對於非默認助理應用，Android 10 的行為沒有變化。
示例音頻 HAL 實現
可以在AOSP中找到符合本文檔指南的音頻 HAL 實施示例。