该小节我们来讲解Android音频系统框架，了解了框架之后，我们才能更加容易的去查看以及分析源码，有了框架才不会遗失方向。
下面是一个大框图，该小节我们将围绕下面的图示进行讲解：
以前总提到，写应用程序的人，不应该关心应用的实现，所以我们会给硬件写一个驱动，然后写应用程序的人直接调用驱动就可以访问硬件了如下：
简单的应用程序使用这种方法是没问题的，但是一些复杂的硬件还是不行，应用程序需要了解很多驱动的接口，于是就进行了改进，在驱动和APP之间加入一些库，APP去访问那些库，进而访问驱动。这些库封装了声卡复杂的使用方法。对于音频系统，库lib有两种选择，一种是alsa-lib，以及alsa-lib的简化版本tinyalsa。
但是应用程序还想偷懒，他还需要去设置各种参数，但是应用程序想参加去设定这些参数，所以变成了如下：
应用程序调用厂家提供的HAL，HAL会去调用lib传入厂家熟悉的参数，然后lib访问驱动。
在前面的分层中只涉及到一个应用程序，那如果有多个应用程序同时播放声音怎么办？那么肯定需要有人去收集他们的声音，混合起来播放，所以出现了如下结构：
APP1,APP2把声音发给AudioFlinger，AudioFlinger进行合并后向下发出。
我们在使用手机的时候，接上耳机，就用耳机播放声音，如果有蓝牙，则使用蓝牙播放声音，如果都没有，就使用喇叭播放，那么谁去决定什么时候，用什么设备播放，在术语上称为AudioPoicy（策略），所以在框图中还要一个AudioPoicy存在，
前面提到了AudioFlinger，他和APP1,APP2都是不同的进程，所以他们是通过binder通信，
这些访问细节被AudioTrack封装，也就是APP通过AudioTrack使用AudioFlinger服务。注意AudioTrack是c++实现的。前面说的APP也代表是c++编写，那如果是使用java编写的呢？所以最后形成了如下框图：
APP1,APP2都为java编写，为java提供一个java层的AudioTrack封装，只不过该AudioTrack会直接访问到C++实现的AudioTrack。C++的AudioTrack去使用AudioFlinger的服务，AudioFlinger在调用厂家提供的tinyalsa这个库，最终访问到驱动。
完成的框图如下：
下面我们进行一些总结：
使用java编写的应用程序，他会调用同样使用java编写的AudioTrack，java编写的AudioTrack他对C++实现AudioTrack的直接引用，C++实现的AudioTrack会跨进程使用AudioFlinger服务，然后这些数据通过厂家提供的HAL文件，去调用tinyalsa，最终发送给驱动。
