概述
Audio系统是Android 平台重要的组成部分，我们将从以下几个方面来讲解：
一·Audio基础知识讲解
二、Android系统中Audio框架
Audio基础知识讲解
我们大家知道声音是由物体振动产生的声波。是通过介质（空气或固体、液体）传播并能被人或动物听觉器官所感知的波动现象。最初发出振动（震动）的物体叫声源。声音以波的形式振动（震动）传播。声音有三要素：
1、音量（Volume）
也叫做响度（Loudness），人耳对声音强弱的主观感觉就是响度，响度和声波 振动的幅度有关。
2、音调（Pitch）
人耳对声音高低的感觉称为音调（也叫音频），音调主要与声波的频率有关。声波的频率高，则音调也高。人类能感 知的频率在20 Hz~20000 Hz之间。
3、音色（Quality）
不同的发声体由于其材料、结构不同，则发出声音的音色也不同。
那我们如何将声音录制到手机，并通过手机播放出来呢，这其中涉及到模拟信号和数字信号的转换，如下图所示
录制过程：
首先麦克风需要捕获声音信息，初始数据是模拟信号；模拟信号通过模-数转换器（ADC)处理成二进制数据。将上一步得到的数据根据需求进行必要的渲染处理，比如音效调整、过滤等等。接下来就可以存储在设备中了，因为这时后原生数据即PCM数据体积太大，通常会通过压缩编码对其压缩处理，如保存为mp3格式、aac格式等。
播放过程：
从存储设备中读取音频文件，根据录制时编码方式进行对应的解码，解码成原始数据后，音频系统为这一播放实例选定最终匹配的音频回放设备（如耳机、扬声器），之后音频数据信号通过数模转换器(DAC)变换成模拟信号，模拟信号经过回放设备，还原出原始声音。
以上我们所说得模拟信号转换成数字信号，这一过程我们称之为音频采样，采样是把连续的模拟信号转换成离散的数字信号，它涉及到以下几点：
样本(Sample)
这是我们进行采样的初始资料，比如一段连续的声音波形
l 采样器(Sampler)
采样器是将样本转换成终态信号的关键。它可以是一个子系统，也可以指一个操作过程，甚至是一个算法，取决于不同的信号处理场景。理想的采样器要求尽可能不产生信号失真
l 量化(Quantization)
采样后的值还需要通过量化，也就是将连续值近似为某个范围内有限多个离散值的处理过程。因为原始数据是模拟的连续信号，而数字信号则是离散的，它的表达范围是有限的，所以量化是必不可少的一个步骤
l 编码(Coding)
计算机的世界里，所有数值都是用二进制表示的，因而我们还需要把量化值进行二进制编码。这一步通常与量化同时进行。
对原始模拟信号进行抽样、量化和编码，我们将得到得PCM音频原始数据，可以通过调整PCM以下几个属性来达到不同的采样需求：
l 采样速率(Sampling Rate)
在将连续信号转化成离散信号时，就涉及到采样周期的选择。如果采样周期太长，虽然文件大小得到控制，但采样后得到的信息很可能无法准确表达原始信息;反之，如果采样的频率过快，则最终产生的数据量会大幅增加，这两种情况都是我们不愿意看到的，因而需要根据实际情况来选择合适的采样速率。由于人耳所能辨识的声音范围是20-20KHZ,所以人们一般都选用44.1KHZ(CD)、48KHZ或者96KHZ来做为采样速率。
l 采样深度(Bit Depth)
我们知道量化(Quantization)是将连续值近似为某个范围内有限多个离散值的处理过程。那么这个范围的宽度以及可用离散值的数量会直接影响到音频采样的准确性。通常有byte、short、float这几种类型。
l 通道数
我们在录制过程中，可以在不同位置放置两套或者多套采集设备，就可以录制两个或者多个通道数据，播放的时候也可以通过不同位置的喇叭、扬声器播放各个通道的声音。通常有单声道、双声道、4.1环绕立体声（5个声道）、7.1环绕立体声（8个声道）。
Android系统中Audio框架
Android系统可以分为应用层、Framework层、系统运行库层、HAL层、Linux内核层，Audio框也是这样，如下图：
接下来分别对各个层次进行介绍
1.应用层：
这是整个音频体系的最上层，因而并不是Android系统实现的重点。在这一层可以调用系统接口编写开发一个音乐播放器。
2.Framework层
在这一层，我们经常用到的MediaPlayer、MediaRecorder、进行音频的播放，录制功能，实际上，Android也提供了另两个相似功能的类，即AudioTrack和AudioRecorder。除此以外，Android系统还为我们控制音频系统提供了AudioManager、AudioService及AudioSystem类。
3.系统运行库层
Framework层的实现需要依赖系统系统运行库层。如前面提到到得AudioTrack.java、MediaPlayer.java、都有对应的系统运行库层的AudioTrack.cpp、mediaplayer.cpp类，它们通过JNI进行调用。这一部分代码集中放置在工程的frameworks/av/media/libmedia中，多数是C++语言编写的
除了上面的类库实现外，音频系统还需要一个“核心中控”，或者用Android中通用的实现来讲，需要一个系统服务,这就是AudioFlinger和AudioPolicyService。它们的代码放置在frameworks/av/services/audioflinger和frameworks/av/services/audiopolicy中。我们在整理相关代码的时候可以分为2个线索。
一是以库为线索。比如AudioFlinger都是在libaudioflinger库中，AudioPolicyService在libaudiopolicyservice库中;而AudioTrack、AudioRecorder等一系列实现则在libmedia库中。
其二，以进程为线索。库并不代表一个进程，进程则依赖于库来运行。虽然有的类是在同一个库中实现的，但并不代表它们会在同一个进程中被调用。比如AudioFlinger和AudioPolicyService都驻留于名为audioserver的系统进程中;而AudioTrack/AudioRecorder和MediaPlayer/MediaRecorder一样实际上只是应用进程的一部分，它们通过binder服务来与其它系统进程通信。
4.HAL层
从设计上来看，硬件抽象层是AudioFlinger直接访问的对象。这说明了两个问题，一方面AudioFlinger并不直接调用底层的驱动程序;另一方面，AudioFlinger上层(包括和它同一层的MediaPlayerService)的模块只需要与它进行交互就可以实现音频相关的功能了。因而我们可以认为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等等库来解决的，而不需要大规模地修改上层实现。换句话说，厂商在定制时的重点就是如何提供这部分库的高效实现了。
