Android 10 改进了用户体验，此体验需要同时进行多项主动音频捕获，例如，如果用户想要使用辅助功能服务提供的语音指令来控制 VoIP 通话或录像机。
音频框架实施了政策，该政策仅允许某些特权应用与常规应用同时捕获音频。
并发政策通过使其捕获的音频静音而不是阻止应用开始捕获来实现。这样，框架就可以动态解决活动捕获用例的数量和类型的变化，而不会阻止应用在可以恢复对麦克风的完全访问权限的情况下开始捕获（在另一个应用完成捕获之后）。
对于音频 HAL 和音频子系统而言，其结果是它们必须同时支持多个活动输入流，即使在某些情况下，只有一个流向活动客户端提供非静音音频。
CDD 要求
请参阅 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 实现的含义
数据使用和用户通知的要求
由于并发麦克风使用如果被滥用可能会泄露用户隐私数据，我们需要对请求持有 Assistant 角色的特权预加载应用应用以下条件和保证。
- 除非用户正在与 Assistant 交互，否则通过麦克风收集的数据不应离开设备。例如，在热词被触发之后。
- 并发监听的应用应在检测到热词后向用户提供视觉提示。这有助于用户理解，进一步的对话将通过不同的应用（例如 Assistant）进行。
- 用户应有权关闭麦克风或 Assistant 触发器。
- 当音频录音被存储时，用户应有权随时访问、查看和删除录音。
Android 10 的功能改进
Assistant 互不阻止
在 Android 9 或更低版本中，当设备上有两个始终在线的 Assistant 时，只有一个可以监听其热词。因此，需要在这两个 Assistant 之间切换。在 Android 10 中，默认 Assistant 可以与其他 Assistant 并发监听。这为同时拥有两个 Assistant 的用户带来了更加流畅的体验。
应用保持麦克风打开
当 Shazam 或 Waze 等应用保持麦克风打开时，默认 Assistant 仍然可以监听热词。
对于非默认 Assistant 应用，Android 10 的行为没有变化。
示例音频 HAL 实现
符合本文档中指南的音频 HAL 实现示例可以在 AOSP 中找到。