由于自己的工作内容是和android 系统audio 相关，虽然只是调用了Android的几个NDK接口进行音频数据的采集以及转码工作，但是我还是趁着这个契机好好的认真的学习一下android audio的整体框架，来丰富自己的知识库。在此记录下自己的学习过程，如果有幸有人在此和我讨论以及分享自己的内容，那么我将不胜感激。话不多说，直接进入正题。
虽然具有争议，但是我仍然认为android系统在本质上与linux系统没有区别，只是对linux系统上的部分系统组件进行了添加以及优化。在用户空间上增加了一套完整的framework框架来实现自己的特定功能需求，所以liunx系统上的很多概念仍然在安卓系统之上仍然适用。
在传统的linux系统上，一个依赖于具体的物理设备的用户系统，大概分为几个部分：物理硬件、操作系统、设备驱动（内核空间）以及用户程序，对此在安卓上也仍然适用。
不过在Android系统上，为了避免Linux系统的对于软件开源的具体要求，将传统的设备驱动程序进行了再次拆分为驱动程序以及用户空间的驱动程序（HAL）。通过这种设计，部分硬件厂商就可以将具有自主产权的设计功能放在HAL层实现，只需要向外提供接口以及动态库就可以，不必将源码开源。随着安卓系统的逐步发展，这种方式在安卓系统上以及成为主流。（部分商用Linux系统项目也将这部分内容借鉴过来了）。
对于用户程序，安卓系统设计了一条自己的框架，通过使用这套框架，应用程序开发人员就可以不用关注于底层特别复杂的逻辑设计，只要关注于自己应用业务就可以了。
至此就形成了安卓系统的整个设计生态。对于Android 的Audio软件架构如下：
（1）由厂商自定义的Audio HAL或者是安卓自带的tinyalsa程序与Linux kernel 驱动程序构建成了安卓系统与硬件交互的最底层软件程序
（2）AudioPolicy与AndroidFlinger为核心构建了Android audio framework层，直接与最底层程序进行交互。
主要职责为：
向HAL层写入音频数据进行音频播放。从HAL层采集音频数据进行音频数据传输或者保存。（audioFlinger）
根据应用场景以及具体配置，对音频通路的控制，即在什么场景之下，声音应该从哪个设备上发声（audioPolicy通过控制audioFlinger来进行实现）
（3）audioTrack以及audioRecord为Android audio framework层对上层提供的接口，用户应用程序可以通过audio Track与Audio fligner进行交互。（用户可以通过audioSystem与audioPolicy进行交互）
（4）应用程序负责客户业务需求的实现。
这样由下到上就构筑了andriod audio的基本框架。