Android音频系统 笔记

心源xinyuan
11 阅读6分钟

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

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

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

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

层级核心组件/模块职责描述
应用层MediaPlayer / MediaRecorder / AudioTrack / AudioRecordJava 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、蓝牙芯片）交互

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

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库。

决策流程：

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

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

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

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

1. 应用层创建AudioTrack

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滤波器）并非无损，高频信息受到平滑衰减。

解决路径

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

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

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

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

七、 总结

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

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