2. Android音频框架基础：AudioTrack/AudioRecord API、AudioPolicyService策略管理、音频焦点(AudioFocus)机制
本章深入剖析Android音频框架的三大核心支柱：面向应用层的音频数据通道API、系统级的音频策略决策引擎，以及多音频流并发时的访问仲裁机制。理解这三层结构是掌握车载音频路由与蓝牙电话集成的先决条件。
2.1 音频数据通道：AudioTrack 与 AudioRecord
AudioTrack 和 AudioRecord 是 Android 框架层提供的最基础的音频数据流 API，分别负责音频数据的输出（播放）与输入（录制）。在 AAOS 车载系统中，这两个 API 是应用与 AudioFlinger 之间的直接桥梁。
2.1.1 AudioTrack（播放通道）
AudioTrack 用于将 PCM 音频数据发送至 AudioFlinger 混音器，最终路由至指定的音频输出设备。其核心工作流程如下：
- 创建配置：指定采样率、通道数、音频格式、缓冲区大小及音频流类型（如
STREAM_MUSIC、STREAM_VOICE_CALL）。 - 缓冲区分配：根据配置在共享内存中分配固定大小的缓冲区，用于应用与 AudioFlinger 之间的数据交换。
- 数据写入：应用通过
write()方法将 PCM 数据填充到缓冲区。 - 混音与播放：AudioFlinger 从缓冲区读取数据，进行混音处理后送入 HAL 层输出。
STREAM_ALARM 或自定义 AudioAttributes 的 USAGE_ASSISTANCE_NAVIGATION_GUIDANCE，以确保其优先级高于媒体播放，但低于电话通话。
2.1.2 AudioRecord（录音通道）
AudioRecord 用于从音频输入设备（如车载麦克风阵列）捕获 PCM 数据。其流程与 AudioTrack 对称：
- 创建配置：指定音频源（如
MEDIA_RECORDER_SOURCE_MIC、VOICE_RECOGNITION）、采样率、格式及缓冲区大小。 - 数据读取：应用通过
read()方法从共享内存缓冲区中获取 AudioFlinger 写入的原始 PCM 数据。 - 后处理：应用层可对原始数据进行降噪、回声消除（AEC）或语音识别处理。
| 特性 | AudioTrack | AudioRecord |
|---|---|---|
| 数据方向 | 输出（播放） | 输入（录制） |
| 核心方法 | write() |
read() |
| 数据源/目标 | 应用 → AudioFlinger → HAL | HAL → AudioFlinger → 应用 |
| 典型车载用途 | 媒体播放、导航提示、TTS | 语音命令、蓝牙电话上行 |
2.2 策略管理核心：AudioPolicyService
AudioPolicyService（APS）是 Android 音频系统的“大脑”，负责制定所有音频路由和策略决策。它不处理音频数据本身，而是根据当前系统状态（设备连接、焦点持有者、策略配置）决定“哪个音频流应该走哪条路”。
2.2.1 核心职责
- 设备选择：根据音频流类型和可用设备（扬声器、蓝牙 SCO、耳机、A2DP 等），选择最佳输出/输入设备。
- 路由策略：执行预定义的策略规则，例如“电话通话期间，媒体音频自动静音或衰减”。
- 策略配置：读取
audio_policy_configuration.xml和audio_policy_engine_configuration.xml文件，定义设备映射、混音规则和动态策略。 - 动态重路由：当设备热插拔（如蓝牙连接/断开）或焦点变化时，实时调整音频路由。
audio_policy_configuration.xml，以定义多区域音频（前后排独立音区）、紧急呼叫（eCall）的高优先级路由，以及蓝牙电话与媒体音频的并发策略。
2.2.2 策略决策流程
当应用请求播放音频时，APS 的决策流程如下：
- 请求到达：AudioFlinger 将播放请求（包含 AudioAttributes）转发给 APS。
- 策略引擎评估：APS 的策略引擎根据当前设备状态、焦点持有者和预定义规则，计算最佳输出设备。
- 路由命令下发：APS 向 AudioFlinger 下发路由命令，指示将特定音频流混音后路由至目标设备。
- 动态调整：若后续发生焦点变化或设备插拔，APS 重新评估并下发新的路由命令。
2.3 音频焦点机制：AudioFocus
音频焦点（AudioFocus）是 Android 提供的一种应用层协作机制，用于管理多个音频流同时播放时的冲突。它不强制静音，而是通过回调通知应用“你应该降低音量”或“你应该暂停播放”。在车载环境中，该机制是确保电话优先于媒体、导航提示不被覆盖的关键。
2.3.1 焦点请求类型
| 焦点类型 | 持续时间 | 典型场景 |
|---|---|---|
AUDIOFOCUS_GAIN |
无限期 | 开始播放音乐、接听电话 |
AUDIOFOCUS_GAIN_TRANSIENT |
短暂 | 导航提示音、短信通知音 |
AUDIOFOCUS_GAIN_TRANSIENT_MAY_DUCK |
短暂，可闪避 | 低优先级通知，允许后台音乐降低音量 |
AUDIOFOCUS_LOSS |
无限期 | 其他应用永久获得焦点（如电话接通） |
2.3.2 焦点交互流程
当应用 A 请求焦点时，系统会检查当前焦点持有者（应用 B），并根据请求类型触发回调：
- 应用 B 收到
onAudioFocusLoss()：应暂停播放或静音。 - 应用 B 收到
onAudioFocusLossTransient()：应暂停播放，但可在焦点回归后恢复。 - 应用 B 收到
onAudioFocusDuck()：应将音量降低至预设的闪避水平（通常为原始音量的 20%-30%）。
2.3.3 焦点与策略的协同
AudioFocus 是应用层的“软”协议，而 AudioPolicyService 是系统层的“硬”策略。两者协同工作：
- 正常场景：应用遵守焦点回调，自行暂停或闪避，APS 无需干预。
- 异常场景：应用未响应焦点丢失，APS 可依据策略规则（如“电话通话时强制将媒体流音量设为 0”）直接干预路由或音量。
- 车载增强：AAOS 通常扩展焦点机制，引入
AUDIOFOCUS_GAIN_TRANSIENT_EXCLUSIVE类型，用于 eCall 或紧急广播，确保其独占音频通道。
2.4 本章小结
Android 音频框架通过 AudioTrack/AudioRecord 提供数据通道，AudioPolicyService 实现策略路由，AudioFocus 机制协调应用间冲突。在 AAOS 车载系统中，这三层均需深度定制：数据通道需适配多通道音频区域，策略服务需定义电话优先的硬规则，焦点机制需扩展以支持紧急呼叫独占。掌握这些基础，是后续实现蓝牙电话音频路由与集成的前提。