Android音频系统笔记

Android音频系统是一个庞大且精密的体系结构，其核心设计哲学是策略与机制的分离 ：AudioPolicyService 负责"决策"（从哪个设备输出、音量多大），AudioFlinger负责"执行"（数据混合、重采样、写入硬件）。

下面从分层架构 、核心组件协同 、设备路由策略 及现代特性演进四个维度展开深度解析。

一、 Android音频系统总体分层架构

Android音频系统从底层硬件到上层应用分为清晰的五层，任何音频数据都必须穿越这些层级：

层级	核心组件/模块	职责描述
应用层	`MediaPlayer` / `MediaRecorder` / `AudioTrack` / `AudioRecord`	Java API接口，供App开发者调用；定义流类型（STREAM_MUSIC、STREAM_RING等）
框架层	`AudioSystem` / JNI (`android_media_AudioTrack.cpp`)	跨进程通信（Binder）桥梁；将应用请求转发至SystemServer中的音频服务
服务层	AudioFlinger + AudioPolicyService	核心中枢。混音、重采样、效果处理（Flinger）；设备选择策略、音量策略（Policy）
HAL层	`audio.primary.xxx.so` / `audio.a2dp.so`	硬件抽象层，定义标准接口；厂商实现具体硬件的控制逻辑
内核层	ALSA / TinyAlsa 驱动	实际与物理设备（Codec、DSP、蓝牙芯片）交互

架构示意图（基于搜索结果整理）：

less 复制代码

App (Java) 
    ↓ [Binder]
AudioFlinger & AudioPolicyService (Native)
    ↓ [HAL API - hw_get_module]
HAL: audio.primary.[soc].so
    ↓ [ioctl / mmap]
Kernel ALSA Driver
    ↓
物理设备 (Speaker/Headset/BT)

二、两大核心服务：AudioFlinger 与 AudioPolicyService

这是Android音频系统最精华的设计，理解二者的关系就掌握了70%的音频逻辑。

1. AudioFlinger：策略的执行者

AudioFlinger是音频数据的搬运工与加工厂 ，驻留在mediaserver进程中。

核心职责：

混音（Mixer）：将多个App的音频流（Track）按权重混合成单一路径的PCM数据。
重采样（Resampler） ：将不同采样率的音频（如44.1kHz CD音质）统一转换为HAL输出设备支持的采样率（默认48kHz）------这是导致"无损音质降级"的元凶。
线程管理 ：针对不同输出设备创建独立的播放线程（PlaybackThread）。例如：PrimaryOutput线程 负责内置扬声器/耳机，A2DP线程 负责蓝牙，Offload线程负责硬件解码直通。

关键数据结构：

mTracks：当前所有活跃音频流的列表。
mHwModules：通过解析audio_policy.conf加载的硬件模块实例。
每个PlaybackThread维护一个环形缓冲区，通过**共享内存（Ashmem）**与客户端的AudioTrack对象交换数据。

2. AudioPolicyService：策略的制定者

AudioPolicyService是指挥官，不接触音频数据，只发号施令。

核心职责：

设备选择：根据音频流类型（Strategy）、设备连接状态（耳机插入/拔出）、策略优先级决定数据输出到哪个硬件接口。
音量策略：定义不同流在不同设备上的音量曲线（例如：通话音量在耳机端和扬声器端的映射表）。
HAL加载 ：启动阶段解析/system/etc/audio_policy.conf，遍历HwModule项，调用AudioFlinger加载对应的HAL SO库。

决策流程：

scss 复制代码

App指定Stream类型（如STREAM_MUSIC）
    ↓
APS映射为Strategy（STRATEGY_MEDIA）
    ↓
getDeviceForStrategy() 根据当前已连接设备列表匹配最高优先级设备
    ↓
根据Device找到绑定的Output Profile
    ↓
通知AudioFlinger将数据路由至对应的Thread

这一过程详细实现在AudioPolicyManager::getDeviceForStrategy()中。

三、数据流与设备路由实战

以播放一首48kHz/16bit的音乐为例，完整的穿越过程如下：

1. 应用层创建AudioTrack

java 复制代码

AudioTrack track = new AudioTrack.Builder()
        .setAudioAttributes(new AudioAttributes.Builder()
                .setUsage(AudioAttributes.USAGE_MEDIA)  // 策略依据
                .build())
        .setAudioFormat(new AudioFormat.Builder()
                .setSampleRate(48000)
                .setEncoding(AudioFormat.ENCODING_PCM_16BIT)
                .build())
        .setBufferSizeInBytes(minBufSize)
        .build();
track.play();

此时，Binder调用进入IAudioFlinger::createTrack()。

2. 策略介入：决定输出设备

AudioPolicyService介入判断：

当前若有线耳机插入 → DEVICE_OUT_WIRED_HEADSET。
若连接了LDAC蓝牙耳机 → DEVICE_OUT_BLUETOOTH_A2DP。
若仅扬声器 → DEVICE_OUT_SPEAKER。

3. AudioFlinger线程路由

根据设备类型，AudioFlinger将Track挂载到对应的PlaybackThread上：

设备为Speaker → 挂载到 Threads.cpp 中的 MixerThread。
设备为A2DP → 挂载到 A2dpPlaybackThread。
若App要求低延迟或独占（AUDIO_OUTPUT_FLAG_DIRECT）→ 创建 DirectOutputThread，绕过混音实现直通。

4. 数据交换与混音

App通过write()或obtainBuffer()将PCM数据写入与AudioFlinger共享的匿名内存。
PlaybackThread的线程循环（threadLoop()）：
1. prepareTracks_l()：标记哪些Track有数据待处理。
2. threadLoop_mix()：调用混音器合并多个Track，若采样率不匹配则触发重采样。
3. threadLoop_write()：通过HAL的out_write()将最终数据推送到驱动。

四、硬件抽象层（HAL）与内核接口

HAL是Android实现厂商适配的关键层，目前存在两套体系：

1. 传统 HAL（legacy）

基于libhardware_legacy，采用动态库直接加载 方式。厂商必须实现AudioHardwareInterface接口，编译产出audio.primary.[soc].so，放置于/vendor/lib/hw/或/system/lib/hw/。

2. Treble 架构下的 HAL（HIDL / AIDL）

从Android 8.0开始，HAL被迁移至独立的/vendor分区，通过HIDL 接口通信。Android 13进一步演进至AIDL HAL，增强了模块化拆分能力。

IDevicesFactory.hal：允许将Primary、A2DP、USB、Offload等实现拆分为独立的SO库，由框架动态加载。
MMAP模式：支持音频数据缓冲区直接映射到应用进程，实现AAudio极低延迟访问。

五、音质妥协与突破：重采样与"比特完美"

搜索结果中一个非常值得关注的现代痛点 ：AudioFlinger默认将全局输出锁定在48kHz。

问题本质

即使播放192kHz/24bit母带级音频，一旦进入AudioFlinger的MixerThread，就会被强制重采样为48kHz输出。
重采样算法（即使是高质量Sinc滤波器）并非无损，高频信息受到平滑衰减。

解决路径

Android 14+ 比特完美 USB 音频：针对外接USB DAC，应用层（如USB Audio Player Pro）可直接通过USB HAL发送原生采样率数据，完全绕过AudioFlinger的混音器。
Direct Offload路径：在音频芯片支持的情况下，将压缩流（如MP3/AAC）直接发送给DSP解码，此时AudioFlinger仅充当转发管道，不干预数据。
AAudio MMAP模式：新音频API允许应用与驱动建立直接内存映射，绕过整个系统服务栈。

六、关键源码定位（供深度调试参考）

若你需要在AOSP中进行修改或调试，以下文件是核心战场：

功能模块	关键源码路径
AudioFlinger主逻辑	`frameworks/av/services/audioflinger/AudioFlinger.cpp`
混音与线程	`frameworks/av/services/audioflinger/Threads.cpp`
AudioPolicy主逻辑	`frameworks/av/services/audiopolicy/AudioPolicyManager.cpp`
客户端AudioTrack	`frameworks/av/media/libmedia/AudioTrack.cpp`
HAL接口定义	`hardware/libhardware/include/hardware/audio.h`
策略配置文件	`device/[vendor]/[device]/audio_policy.conf`

七、总结

Android音频系统本质上是一个面向策略的多路输出重定向框架 。其核心矛盾在于**通用性（混音、多任务）与高保真（直通、低延迟）**之间的权衡。

AudioFlinger 保障了系统声音的"混而不乱"，但默认引入了重采样损耗；
AudioPolicyService 实现了设备的智能切换，但也增加了路由的复杂性；
HAL层 给予了厂商极大的自由度，也是碎片化的源头。

Android音频系统 笔记