Android Audio官方文档分析

目录

第一节        本文的主要内容

第二节        官方文档的目录分析

第二节        Android Audio架构分析

第三节        配置音频

第五节        Tee Sink的作用

---

第一节        本文的主要内容

       对于开发者而言，掌握第一手开发资料尤其重要，官方文档毋容置疑是妥妥的一手资料，如果官方都出现问题，那么使用官方提供的资源进行开发，也会受到极大地影响，官方虽然不一定完全正确，但是官方作为顶级的开发者，其资料大有参考价值和意义。反观大部分资料（博客、书籍、视频这些）往往都是二手的资料，大多都是他人参考了官方的说明文档，外加自己的理解写出来的文章。虽然这些资料很详细，但是行业不同、个人水平不同，导致内容方面都参差不齐。

       本文就解析一下Android Audio的官方开发文档，也就是安卓向开发者提供的说明文档。由于工作原因，笔者就侧重于Android 9版本与HAL&Framework的分析。

        Android Audio官方开发文档的链接如下：https://source.android.com/devices/audio（有墙）

        Android整个框架的开发文档如下（本文不作详细分析）：https://source.android.com/devices/architecture

第二节        官方文档的目录分析

        Android官方的目录如下：

        其中Android Audio的架构描述存在于目录“概览”，使用Android Audio的方法位于“实现”目录，安卓官方推荐的调试工具位于目录“调试”，笔者着重于这三个目录进行分析，其余内容，读者可根据自己的工作需要进行分析。

第二节        Android Audio架构分析

        Android官方给出的框架如下所示：

        第一眼看上感觉十分的简洁，但是又简明概要的说出了整个Android Audio架构，图中有给出了所有架构相关的目录，并且指明了调用关系，和各层的主要文件。

        从JNI开始分析，JNI的最主要目的是使得Java代码和其他语言写的代码进行交互，也就是JNI上层的部分多用JAVA这种编程语言书写，换句话来说Android官方推荐我们进行应用级开发的编程语言就是JAVA语言，经过JNI的连接后，JAVA便可以很好的与C/C++进行交互。这部分如果出现问题，那么估计绝大多数问题都是JAVA那边的调用出现了问题，例如参数的错误使用，函数的使用不规范。

        然后JNI连接了NATIVE FRAMEWORK层，在Android中FRAMEWORK层按照编程语言的使用，可以分为JAVA FRAMEWORK和NATIVE FRAMEWORK层次，JNI上层的连接APP FRAMEWORK其实就是JAVA FRAMEWORK（APP主要用JAVA语言编写），而NATIVE FRAMEWORK更多使用的是C++语言编写的。在NATIVE FRAMEWORK层中最主要的是AudioRecord.cpp和AudioTrack.cpp文件在起作用，他们分别对应这Audio的录音和放音功能。

        NATIVE FRAMEWORK层后面连接的是Binder层次，Binder是一种IPC机制，他没有起实际控制着外设的功能，更加偏向于管理（这就是为什么我在博客Android Audio Architecture_晓文同学的博客-CSDN博客中不把Binder加入数据流和控制流的原因）。而Binder机制的出现和Linux的框架有着很大的原因，下图是Linux中数据传输的机制：

这个过程需要拷贝两次数据，但是借助于mmap()系统调用后可以减少一次数据拷贝，如下图：

然后Android给它套上一层外壳就变成了如下：

这方面的知识可以参考博客：Android跨进程通信：图文详解 Binder机制 原理_Carson带你学Android的博客-CSDN博客_跨进程通信，本文不细讲。Binder文件中出现了一个重要文件IAudioFling.cpp，AudioFling是音频策略的执行者，负责输入输出流设备的管理及音频流数据的处理传输，它与本文第四节的Audio_Policy结合使用，就可以实现对音频数据流的管理。

       Binder层后面连接的是MEDIA SEVER层，值得注意的是这个连接关系是双向连接，这一点其实理解了Binder的实现机制其实不难理解。举个例子，IAudioFlinger.cpp的执行效果就是上图的client进程，通过binder驱动便可以连接上MEDIA SEVER层中的AudioFlinger Server。

       MEDIA SEVER层连接了HAL层，HAL层就是硬件抽象层，对Linux Kernel进行进一步的封装。

第三节        配置音频

        在Android Audio官方文件的“实现”中有介绍如何配置安卓的音频。在“实现\预览”中有这样的总结：“除了实现音频 HAL 之外，您还必须创建音频政策配置文件，用于描述您的音频拓扑，并将 HAL 实现打包到共享库中。您还可以配置预处理效果，如自动增益控制和噪音抑制。”，这句话简短却很精髓，仔细分析一下，官方指出来的配置Audio步骤就是以下四个步骤：

1. 实现音频 HAL：即实现hardware/libhardware/include/hardware/audio.h（音频设备的主函数）与hardware/libhardware/include/hardware/audio_effect.h（可应用于音频的效果）的所有接口。可参考参阅 device/samsung/tuna/audio 中的 Galaxy Nexus 实现。
2. 创建音频政策配置文件，用于描述音频拓扑：对于安卓9版本，需要使用XML格式的文件去描述音频拓扑。音频政策配置文件是 audio_policy_configuration.xml，位于 /system/etc。可参考官方中的模板实现。
3. 创建音频政策配置后，须将 HAL 实现打包到共享库中，并将其复制到相应位置。官方已在“实现/共享库”中说明具体的做法。
4. 前三步是必须需要完成的，而第四步可以依据实际情况判断是否需要完成。第四步可以配置预处理效果，如自动增益控制和噪音抑制。

第五节        Tee Sink的作用

        面对安卓庞大的源码体系，如果缺乏调试工具，那么查找问题和寻找漏洞会成为一个难点。对于Android Audio部分，官方推荐我们使用的工具是Tee Sink，该工具可用于调试AudioFlinger，主要功能是获取最近音频的短片段。值得注意的是Tee Sink是默认不开启的。具体开启以及使用步骤可以查看在Android Audio官方文件的“调试”章节。