Android 音频框架：
1，与应用程序开发有直接关联的是MediaPlayer，MediaRecorder。
音频系统的核心由AudioFlinger、AudioPolicyService、AudioTrack/AudioRecorder三部分构成，其中AudioFlinger、AudioPolicyService属于system service，驻留在audioserver进程，负责不断地处理AudioTrack/AudioRecorder的请求。
依据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初始化时根据加载的库来填充。
如果觉得《android 音频子系统框架（一）》对你有帮助，请点赞、收藏，并留下你的观点哦！
