Android Audio音频部分官网文档中文翻译

Audio

安卓音频硬件抽象层（HAL）通过 android.media 包中的音频框架 API 函数将系统上层和底层的音频驱动与硬件实体

联系起来。这一章节的内容包括实现安卓音频功能的方法说明以及如何提高性能。

Audio 架构

---

安卓音频架构决定了各音频功能模块的实现方式，并列出了相关代码在工程中的路径。

图1. 安卓音频架构图

Application framework（应用层框架）

应用层框架中包含了使用 android.media 包中的 API 函数来与音频硬件交互的应用程序代码。

在内部具体实现中，这些上层应用程序实际调用了相应的 JNI 类通过本地框架代码来完成与音频硬件的交互。

JNI（本地接口）

JNI 代码存在于 android.media 包中，通过下层的本地代码访问音频硬件。相关源码在工程中位于 framework/base/core/jni/ 和

framework/base/media/jni/ 路径下。

Native framework（本地框架）

本地框架在系统的下层实现了一个与上层 android.media 包功能相同的库，这个库通过 Binder IPC 代理机制访问 MediaServer 进程中

音频相关的服务。本地框架的代码在工程中位于 frameworks/av/media/libmedia 路径下。 （博主注：因为底层 HAL 和 Driver 都是使用

C/C++ 编写的，当上层 APP 通过 Java Framework 发起请求时并不能直接来调用这些接口，所以需要在底层再使用 C/C++ 实现一个和

Java Framework 功能相同的 Native Framework，将 Java Framework 的调用申请翻译成底层 C/C++ 接口可以理解的请求。）

Binder IPC（Binder机制进程间通信）

Binder IPC 代理机制实现了跨进程通讯。相关代码在工程中位于 frameworks/av/media/libmedia 路径下，并以字母 I（大写i）

作为文件开头。 （博主注：Android 对于多媒体的支持并不是在 APP 需要播放/录制音频才启动一个进程来实现这个功能，

而是在系统启动时就会通过在 init.rc 文件中写入命令启动一个 MediaServer 进程，MediaServer 进程通过 MediaPlayerService 

来“监听”来自 APP 的音频播放/录制请求。从 APP 发起的音频播放/录制申请会按照 APP-->JavaFramework--> JNI-->

NativeFramework-->Binder 的流程找到 MediaServer 进程并传递多媒体操作的请求。 ）

Media server（多媒体服务进程）

在 MediaServer 进程中含有多个音频服务，它们是真正直接和 HAL 接口进行交互的那部分。MediaServer 进程的相关代码位于工程的

frameworks/av/sevices/audioflinger/ 路径下。

HAL（硬件抽象层）

HAL 层定义了 MediaServer 中各音频服务所调用函数的标准接口，我们需要根据需求为音频硬件实现这些接口。音频 HAL 接口的代码声明

位于工程中 hardware/libhardware/include/hardware/ 路径下，更多细节请阅读该路径下的 audio.h 文件。 （博主注：如果使用的是

老版本安卓音频 HAL 架构，则代码位于 hardware/libhardware_legacy/ 路径下）

Kernel driver（内核驱动）

音频驱动向上为 HAL 提供访问接口，向下直接操作硬件。你可以使用高级Linux音频架构（ALSA）、开放音频系统架构（OSS）或自定义的

架构来编写音频驱动（HAL层并不关心底层驱动的具体实现，它们只管调用底层驱动所提供的接口函数）。

注意：如果你使用的 ALSA 驱动架构，那么我们推荐你在用户空间使用external/tinyalsa 以避免证书不兼容的问题（标准的用户空间库使用 GPL 协议进行授权，而 tinyalsa 使用 BSD 协议进行授权）。

基于 Open SL ES 的 Android native audio

这部分 API 被作为 Android NDK 的一部分进行提供，和 android.media 包在音频架构中属于同一层级。