Android 音频子系统(1) ---- 架构分析

本系列文章基于Android14源码进行分析解读，部分框图直接使用了原作者的图片，侵权必删。

本章参考文章

Android13音频子系统分析(一)---整体架构_audio preselection descriptor-CSDN博客

Android Framework 音频子系统（02）音频系统框架_android音频策略蓝牙-CSDN博客

---

一、概述

音频子系统是Android框架中一个较为复杂的系统，涉及到较多的模块。一个应用涉及到的API层面包括APP层，FrameWork层，Native层，HAL层，Driver层。一个应用运行在系统的4个进程中：

1.  APP应用本身进程，使用应用层API：AudioManager，AudioTrack，AudioRecord；
2. SystemServer进程，使用框架层的API：AudioService
3. AudioService进程，使用Native层的API：AudioFlinger，AudioPolicyService
4. AudioHAL进程，使用HAL层的API：Device，StreamOut，StreamIn

二、各个层级

1、APP应用层

应用层的API源码位置：/frameworks/base/media/java/android/media/

这部分代码运行在调用API接口的APP进程中(譬如抖音，QQ音乐)，是Android FW对外提供的音频接口。主要模块包括：

• AudioTrack.java：为APP提供音频数据的播放API
• AudioRecord.java：为APP提供音频数据的录制API。
• AudioManager.java：为APP提供音量控制、音频焦点获取的管理API，及音频系统状态的回调通知。

AudioTrack和AudioRecord API有一部分业务逻辑，但是更多的逻辑处理都会通过Binder跨服务调用到框架层甚至Natvie层。

AudioManager通过binder与Framework层的AuidoService服务通信，完成音频焦点，音量控制及音频播放状态的设置及获取。

2、Framework框架层

FW框架层是音频设备路由管理、音量控制、焦点控制的具体实现模块。它主要包含如下几个模块：

1. AudioService：音频服务核心模块，由4个小弟配合完成音频管理；
2. AudioDeviceBroker：用于管理音频设备路由策略(Android11对AudioService重构而产生的模块)，它包含两个子模块AudioDeviceInventory和BtHelper。AudioDeviceInventory管理所有设备的路由及状态，BtHelper用于和蓝牙层模块交互，监听蓝牙设备的连接状态；
3. MediaFocusControl：音频焦点控制模块；
4. PlaybackActivityMonitor：音频播放事件监听模块；
5. RecordingActivityMonitor.java：音频录制事件监听模块；

3、Native层

Native层包含两大模块：AudioFlinger和AudioPolicyService，运行在AudioServer进程中。AudioService之所以把两个模块放在一个进程中，主要一个考虑就是两个模块需要互相交换以获取音频系统的信息：音频策略需要获取底层的硬件信息，这个只能通过AudioFlinger这个接口；而音频设备状态的变化也需要AF通知到Policy服务。

3.1 AudioFlinger模块

AudioFlinger主要包含3个主要的子模块：AudioHwDevice、PlaybackThread/RecordThread、PlaybackTrack/RecordTrack。（这里暂时不提音效子模块）

•    AudioHwDevice是一种抽象，并不是指扬声器、听筒、耳机这种真实的物理设备，而是指不同的Audio HAL module，比如primary module、a2dp module等，也可以理解成是音频框架层定义的一种虚拟设备。它与Audio HAL层的DeviceHal是对应的关系。
•  PlaybackThread/RecordThread是由AudioFlinger启动的负责音频数据传输的线程，播放和录制的核心流程都在这里面实现。它与Audio HAL层的StreamHal是对应的关系。
• PlaybackTrack/RecordTrack对应的是API层的AudioTrack/RecordTrack,它相当于是服务端。

   以下是AudioFlinger核心子模块的类图：

TrackHandle只是一个代理，负责与客户端交互。

Track类中的设计音频流的信息主要在Thread中处理，Thread在音频流中是一个承上启下的存在，所以这里也顺带分析这两个类图的结构：

3.2 AudioPolicyService模块

APS包含3个核心的子模块:AudioPolicyService、AudioPolicyManager和Engine。

• Engine负责存储设备路由策略和音量大小配置；
• AudioPolicyManager负责设备路由和音量控制的具体实现；
• AudioPolicyService负责对外提供Binder接口和其它模块进行交互；

三者的调用关系为：AudioPolicyService - AudioPolicyManager - Engine

4、AHAL层

Audio HAL层是Android系统为各个硬件Vendor厂商抽象的一层，以隔离硬件实现的差异，在Treble机制之后变成一个独立的服务。AOSP/AAOS 没有为AHAL提供实现源码，由芯片Vendor厂商实现并由终端用户客制化。

---

三、总结

下面是整个音频链路核心模块的链路图。

总体来说，一个完整的音频在需要完成下面几个步骤才可以正常的启播：

1. 创建AudioTrack：根据音频流属性获取支持该音频流播放的设备(AudioPolicyService)，AudioFlinger根据相关属性打开设备(AudioHAL)并创建与设备关联的播放线程(AudioPlaybackThread)，最后将创建的track与播放线程关联，完成数据流的打通；
2. 申请音频焦点：调用AudioManager接口尝试获取音频，AudioManger将申请转发到AudioServer进行处理。AudioServer调用内部的MediaFocusControl模块处理焦点申请。
3. MediaFocusControl会根据是否支持外部焦点策略进而确定是按照AOSP的手机策略还是AAOS的车机策略执行焦点仲裁，并返回仲裁结果到应用；
4. 应用根据焦点仲裁结果执行相关的音频处理：启播，暂停，恢复，衰减，停止。