Android -- Audio Native服务之启动流程分析(一).doc

Android -- Audio Native服务之启动流程分析（一） Android中的Audio系统是比较庞大、繁杂的一部分内容， 其中会涉及较多的音频编解码、多媒体制式与Android Audio HAL设备管理的知识。随着Android的发展，其所支持的音频设备也变得越来丰富，如扬声器、耳机、听筒等等；这种变化也为Android管理如此丰富的音频设备以及如何正确、合理地切换音频输出提出了更高的要求。面对如此繁杂的管理要求，我们分析Android Audio服务的历程想必也不会轻松。接下来，我们会以Audio Native服务的启动为入口，以其基本实现流程为重点，抓住代码中的各个关键点，循序渐进地学习Android Audio部分的知识，先让我们对它有一个基本的认识和了解；其他的代码细节分析，则需要我们在工作、学习中花费更多的时间去揣摩和思考了。 Android Audio部分最主要的Native服务有两个：AudioFlinger和AudioPolicyService。 AudioFlinger是Android Audio系统的核心与中枢。从上，它为Android Audio API实现提供具体的功能接口；向下，它与Audio HAL层交互，管理音频设备。我们知道HAL层是Android对各个物理设备的代码抽象。HAL层中封装了操作物理设备的接口，通过调用这些接口，我们就可以操作设备，实现我们自己的功能。又由于AudioFlinger负责管理这些Audio设备，所以我们可以猜测它有一套自己的机制，来区分和管理这些Audio Interface。 同时，AudioFlinger直接与HAL交互，它其中也必然实现了音频数据管理、音频输入输出等功能。我们也要注意，Android中支持多种音频设备，那么就需要有一位大师来管理音频数据到底从哪种设备输入或者输出；这就牵扯到一种策略制定的问题，它指引音频数据的流向，即与哪种物理设备交互。既然是制定策略，那这位大师当然就是AudioPolicyService。基于这种分工，我们可以得出：AudioFlinger是一个工作繁重的服务，它是Audio策略的功能执行者，直接负责音频数据与音频设备的交互；而策略由AudioPolicyService制定，它负责把控AudioFlinger的工作方向。 有了这些概念，我们再去分析AudioFlinger和AudioPolicyService的服务启动过程。与之前不同的是，较新的Android系统中，Audio相关的服务都被移动了audioserver进程中。系统启动的时候，会创建该进程，其中就有AudioFlinger和AudioPolicyService的启动处理： [cpp] view plain copy 在CODE上查看代码片派生到我的代码片 int main(int argc __unused, char **argv) { signal(SIGPIPE, SIG_IGN); bool doLog = (bool) property_get_bool(ro.test_harness, 0); pid_t childPid; // FIXME The advantage of making the process containing media.log service the parent process of // the process that contains the other audio services, is that it allows us to collect more // detailed information such as signal numbers, stop and continue, resource usage, etc. // But it is also more complex. Consider replacing this by independent processes, and using // binder on death notification instead. if (doLog (childPid = fork()) != 0) { // media.log service //prctl(PR_SET_NAME, (unsigned long) media.log, 0, 0, 0); // unfortunately ps ignores PR_SET_NAME for the