一.Android音频框架
Application 层：
音乐播放器软件等。
Framework 层：
Android也提供了另两个相似功能的类，即AudioTrack和AudioRecorder。
MediaPlayerService内部的实现就是通过它们来完成的，
只不过MediaPlayer/MediaRecorder提供了更强大的控制功能，相比前者也更易于使用。
除此以外，Android系统还为我们控制音频系统提供了AudioManager、AudioService及AudioSystem类。
这些都是framework为便利上层应用开发所设计的。
Libraries 层：
framework 只是向应用程序提供访问 Android 库的桥梁，具体功能放在 库 中完成。
比如上面的 Audio Track、Audio Recorder 、MediaPlayer 和 MediaRecorder 等库中都能找到相对应的类。
1、frameworks/av/media/libmedia【libmedia.so】
2、frameworks/av/services/audioflinger【libaudioflinger.so】
3、frameworks/av/media/libmediaplayerservice【libmediaplayerservice.so】
HAL 层：
从设计上来看，硬件抽象层是AudioFlinger直接访问的对象。
这说明了两个问题，一方面AudioFlinger并不直接调用底层的驱动程序;
另一方面，AudioFlinger上层模块只需要与它进行交互就可以实现音频相关的功能了。
因而我们可以认为AudioFlinger是Android音频系统中真正的“隔离板”，无论下面如何变化，上层的实现都可以保持兼容。
音频方面的硬件抽象层主要分为两部分，即AudioFlinger和AudioPolicyService。实际上后者并不是一个真实的设备，只是采用虚拟设备的方式来让厂商可以方便地定制出自己的策略。
抽象层的任务是将AudioFlinger/AudioPolicyService真正地与硬件设备关联起来，但又必须提供灵活的结构来应对变化——特别是对于Android这个更新相当频繁的系统。
比如以前Android系统中的Audio系统依赖于ALSA-lib，但后期就变为了tinyalsa，这样的转变不应该对上层造成破坏。
因而Audio HAL提供了统一的接口来定义它与AudioFlinger/AudioPolicyService之间的通信方式，这就是audio_hw_device、audio_stream_in及audio_stream_out等等存在的目的。这些Struct数据类型内部大多只是函数指针的定义，是一些“壳”。当AudioFlinger/AudioPolicyService初始化时，它们会去寻找系统中最匹配的实现(这些实现驻留在以audio.primary.,audio.a2dp.为名的各种库中)来填充这些“壳”。
根据产品的不同，音频设备存在很大差异，在Android的音频架构中，这些问题都是由HAL层的audio.primary等等库来解决的，而不需要大规模地修改上层实现。换句话说，厂商在定制时的重点就是如何提供这部分库的高效实现了。
Tinyalsa 层：
源码在external/tinyalsa目录下
Tinyalsa：tinyplay/tinycap/tinymix，这些用户程序直接调用 alsa 用户库接口来实现放音、录音、控制。
Kernel部分：
ASoC被分为Machine、Platform和Codec三大部分。
Machine用于描述设备组件信息和特定的控制如耳机/外放等。
Platform用于实现平台相关的DMA驱动和音频接口等。
Codec用于实现平台无关的功能，如寄存器读写接口，音频接口，各widgets的控制接口和DAPM的实现等。
