android 音频子系统框架（一）

爱被打了一巴掌 2022-06-05 02:30 498阅读 0赞

Android 音频框架：

1，与应用程序开发有直接关联的是MediaPlayer，MediaRecorder。

音频系统的核心由AudioFlinger、AudioPolicyService、AudioTrack/AudioRecorder三部分构成，其中AudioFlinger、AudioPolicyService属于system service，驻留在audioserver进程，负责不断地处理AudioTrack/AudioRecorder的请求。

![Center][]

依据Android音频框架图的几个层次结构：应用层，framework层，库层，hal层，kernel层来细分音频系统。

1），app，比如音乐播放器

2），framework层，开发音频产品使用最多的两个类MediaPlayer，MediaRecorder；还有两个专门用于音频管理的类：AudioTrack，AudioRecorder，系统服务MediaPlayerService内部的音频实现就是通过这两个类完成的。此外，还有AudioManager，AudioService，AudioSystem类。

3），Libraries，framework层的java类只是app跟库文件的中介，这些中介并不会完全去实现相关的功能，真正的功能实现是在底层库中。跟音频相关的库很多，如：

\\frameworks\\av\\media\\libmedia，包括的类有：AudioRecorder.cpp，AudioTrack.cpp，MediaRecorder.cpp，MediaPlayer.cpp等；

音频系统的核心服务类：AudioFlinger.cpp，libaudioflinger在\\frameworks\\av\\services\\audioflinger路径下；

AudioPolicyService.cpp，libaudiopolicyservice在路径：frameworks\\av\\services\\audiopolicy下。

还有一个重要的系统服务MediaPlayerService，libmediaplayerservic在目录：\\frameworks\\av\\media\\libmediaplayerservice下。

其中，AudioTrack，AudioRecorder，mediaPlayer,MediaRecorder是应用进程的一部分，通过Binder服务来与系统进程通信。

4），HAL，音频硬件抽象层主要分为两个核心：AudioFlinger和AudioPolicyService。AudioFlinger是硬件抽象层的服务对象，一方面AudioFlinger可以不用直接调用底层的音频驱动，另一方面AudioFlinger的上层（包括同层的MediaPlayerService）模块，只需要与他进行通信就可以实现音频相关的功能了。AudioPolicyService实际并不是一个真实的设备，只是采用虚拟设备的方式让厂商可以方便的定制自己的“音频策略”。

抽象层的任务是将AudioFlinger/AudioPolicyService真正的与硬件设备关联起来，但是又要保证底层的变化不对上层造成影响。所以Hal层提供了统一的接口来定义跟audioFlinger，AudioPolicyService之间的通信方式，这就是audio\_hw\_device,audio\_stream\_in, audio\_stream\_out等结构体，这些struct数据类型内部只是提供了函数指针的定义，真正的实现要在AudioFlinger、AudioPolicyService初始化时根据加载的库来填充。

[Center]: /images/20220605/133b38cd80aa4b1fa60c042ada7219b0.png