android audio系统变化说明,Android Audio音频系统的深入理解

一、Audio音频架构简介

二、Android Audio系统框架

三、Audio架构以及各层的代码分布图

四、音频框架在Android系统中的进一步细化

五、创建声卡和注册声卡

六、Android Audio系统的结构

七、Audio音频原理介绍

八、Audio音频策略制定与策略执行的调用流程

九、Android AudioPolicyService服务启动过程

十、Android系统中所有的音频接口设备保存到AudioFlinger的成员变量mAudioHwDevs中

十一、audio_policy.conf同时定义了多个audio接口

十二、通过AudioFlinger的loadHwModule加载各audio接口对应的库文件实现调用PlaybackThread播放线程或RecordThread录音线程

十三、AudioFlinger的openInput()方法调用流程分析

十四、AudioFlinger的openOutput()方法的调用流程分析

十五、Audio系统为了能正常播放音频数据，需要创建抽象的音频输出接口对象，打开音频输出过程

十六、打开音频输入的流程

十七、打开音频输出后，在AudioFlinger与AudioPolicyService中的表现形式

十八、打开音频输入后，在AudioFlinger与AudioPolicyService中的表现形式

十九、AudioPolicyService加载完系统定义的所有音频接口，并生成相应的数据对象

二十、AudioPolicyService与AudioTrack和AudioFlinger的关系

二十一、AudioPolicyService注册名为服务的流程

二十二、AudioTrack构造过程

二十三、AudioTrack和AudioFlinger的关系

二十四、audio_policy与AudioPolicyService、AudioPolicyCompatClient之间的关系

一、Audio音频架构简介

APP

整个音频体系的最上层

Framework

MediaPlayer和MediaRecorder、AudioTrack和AudioRecorder，Android系统为控制音频系统提供了AudioManager、AudioService及AudioSystem类，这些都是framework为便利上层应用开发所设计的

Libraries

系统服务AudioFlinger和AudioPolicyService(比如:ServiceManager、LocationManagerService、ActivityManagerService等等)，音频体系中另一个重要的系统服务是MediaPlayerService

HAL

硬件抽象层是AudioFlinger直接访问的对象，这说明了两个问题，一方面AudioFlinger并不直接调用底层的驱动程序;另一方面，AudioFlinger上层(包括和它同一层的MediaPlayerService)的模块只需要与它进行交互就可以实现音频相关的功能了。因而我们可以认为AudioFlinger是Android音频系统中真正的“隔离板”，无论下面如何变化，上层的实现都可以保持兼容。音频方面的硬件抽象层主要分为两部分，即AudioFlinger和AudioPolicyService。实际上后者并不是一个真实的设备，只是采用虚拟设备的方式来让厂商可以方便地定制出自己的策略，抽象层的任务是将AudioFlinger/AudioPolicyService真正地与硬件设备关联起来

以前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音频系统的时候分为两条线索

以库为线索，比如:AudioPolicyService和AudioFlinger都是在libaudioflinger库中，而AudioTrack、AudioRecorder等一系列实现则在libmedia库中

以进程为线索，库并不代表一个进程，进程则依赖于库来运行。虽然有的类是在同一个库中实现的，但并不代表它们会在同一个进程中被调用。比如AudioFlinger和AudioPolicyService都驻留于名为mediaserver的系统进程中，而AudioTrack/AudioRecorder和MediaPlayer/MediaRecorder一样实际上只是应用进程的一部分，它们通过binder服务来与其它系统进程通信

完整的文档，如下所示:

https://mp.weixin.qq.com/s/THbeU39kZK0gi0qab3IWng