Android 10 改進了需要同時進行多個活動音頻捕獲的用戶體驗，例如，如果用戶想要使用無障礙服務提供的語音命令來控制 VoIP 呼叫或錄像機。
音頻框架實現了僅允許某些特權應用程序與常規應用程序同時捕獲的策略。
並發策略是通過使其捕獲的音頻靜音而不是阻止應用程序開始捕獲來實現的。這允許框架動態解決活動捕獲用例的數量和類型的變化，而不會阻止應用程序在另一個應用程序完成捕穫後可以恢復對麥克風的完全訪問的情況下開始捕獲。
音頻 HAL 和音頻子系統的結果是它們必須同時支持多個活動輸入流，即使在某些情況下，只有一個流向活動客戶端提供非靜默音頻。
CDD要求
見CDD對於並發拍攝支持的要求。
從音頻 HAL 捕獲情況
在活動輸入流的數量、輸入設備選擇或預處理配置方面，並發捕獲場景可能會導致不同的情況。
並發可能發生在以下情況之間：
- 來自應用處理器 (AP) 的幾個輸入流
- 輸入流和語音通話
- 輸入流和實現低功耗啟動指令檢測的音頻 DSP
AP 輸入流的並發活動
音頻策略配置文件audio_policy_configuration.xml所使用的音頻框架，以確定有多少輸入流可以同時打開並激活。
在最低限度，音頻HAL必須支持每個輸入簡檔（中的至少一個實例mixPort角色的sink的打開和活動配置文件中列出）。
設備選擇
當多個活動客戶端連接到同一個 HAL 輸入流時，框架會根據用例優先級為該輸入流選擇合適的設備。
當多個輸入流處於活動狀態時，每個流都可以有不同的設備選擇。
如果技術兼容，建議音頻 HAL 和子系統允許從不同設備（例如藍牙耳機和內置麥克風）捕獲不同的流。
如果存在不兼容（例如兩個設備共享相同的數字音頻接口或後端），音頻 HAL 必須選擇哪個流控制設備選擇。
在這種情況下：
- 結果狀態必須一致，並在重複相同場景時提供相同的設備選擇。
- 當並發狀態結束時，必須將剩餘的活動流路由到此流上最初請求的設備。
如果優先順序由活性用例之間的音頻HAL定義，按照相同的順序中找到的source_priority()中frameworks/av/services/audiopolicy/common/include/policy.h
預處理選擇
音頻框架可以請求預處理使用所述輸入流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應輸入的個人資料（暴露mixPort角色的sink從設備的可用路由） AudioDevice.IN_TELEPHONY_RX 。
當呼叫被連接（音頻模式是AudioMode.IN_CALL ），它應該有可能具有從裝置的至少一個活性捕獲流AudioDevice.IN_TELEPHONY_RX 。
當通話處於活動狀態時從輸入設備捕獲
當一個呼叫是活動的（音頻模式是AudioMode.IN_CALL ），它應該是可能的，以打開和如在章節指定激活從AP輸入流AP輸入流的並行活動。
但是，設備選擇和預處理的優先級應始終由語音呼叫驅動，以防與來自 AP 輸入流的請求發生衝突。
從 DSP 和 AP 並發捕獲
當音頻子系統包含支持低功耗音頻上下文或啟動指令檢測功能的 DSP 時，實現應支持來自 AP 和音頻 DSP 的並發捕獲。這包括在與初始檢測相位和捕獲由AP既捕獲由DSP AudioSource.HOTWORD檢測之後由DSP觸發。
這應該是反映了同時捕獲標誌報告通過實施描述符的聲音觸發HAL： ISoundTriggerHw.Properties.concurrentCapture = true 。
音頻HAL也應該揭露和輸入配置文件具體由標誌標識的啟動指令捕捉AudioInputFlag.HW_HOTWORD 。該實現應支持在此配置文件上打開和激活至少等於聲音觸發器 HAL 可以同時加載的聲音模型數量的流。
當其他輸入配置文件處於活動狀態時，應該可以從該輸入配置文件中捕獲。
對 Google 助理實施的影響
數據使用要求和用戶通知
因為並發麥克風使用，如果被濫用，可能會洩露用戶隱私數據，我們需要以下條件和保證應用於要求擔任助理角色的特權預加載應用程序。
- 除非用戶與 Google 助理交互，否則通過麥克風收集的數據不應離開設備。例如，在觸發啟動指令之後。
- 在檢測到啟動指令後，同時偵聽的應用程序應向用戶提供視覺提示。這有助於用戶了解進一步的對話將通過不同的應用程序進行，例如助手。
- 用戶應該能夠關閉麥克風或助理觸發器。
- 存儲錄音後，用戶應該能夠隨時訪問、查看和刪除錄音。
Android 10 的功能改進
助手不會互相阻塞
在 Android 9 或更低版本上，當設備上有兩個永遠在線的助手時，只有其中一個可以監聽其啟動指令。因此，需要在兩個助手之間切換。在 Android 10 中，默認助手可以與其他助手同時收聽。這為使用兩個助手的用戶帶來了更流暢的體驗。
保持麥克風打開的應用程序
當 Shazam 或 Waze 等應用程序將麥克風保持打開狀態時，默認助手仍可監聽啟動指令。
對於非默認助手應用，Android 10 的行為沒有變化。
示例音頻 HAL 實現
符合本文檔中的指南音頻HAL實施的實例中可以找到AOSP 。