以上对AudioFlinger进行的分析，主要是通过hw_get_module_by_class()找到模块接口名字if_name相匹配的模块库，加载，然后audio_hw_device_open()调用模块的open方法，完成音频设备模块的初始化。
留意AudioFlinger的构造函数只有简单的私有变量的初始化操作了，把音频设备初始化放到onFirstRef()，Android终于改进了这一点，好的设计根本不应该把可能会失败的操作放到构造函数中。onFirstRef是RefBase类的一个虚函数，在构造sp的时候就会被调用。因此，在构造sp
Android音频系统有两大服务：一是AudioFlinger，二是AudioPolicyService。AudioFlinger负责向下访问AudioHardwareInterface，实现音频PCM数据的混音/输入/输出，实现音量调节；AudioPolicyService负责音频输入输出设备的连接状态，音频策略调度
即音频设备（如本地CODEC、Bluetooth A2DP、Headset）的切换策略（注意它只是负责策略，真正的切换操作是在AudioFlinger中的openOutput，毕竟AudioFlinger负责操作底层音频硬件）。AudioPolicyService在以后的章节详细分析，这里主要探讨A2DP-Audio是如何注册到AudioFlinger中，并简要提及音频PCM数据流向。好的平台软件应有这样的一个抽象层：向下提供一套固定的接口，不同的硬件设备根据这些接口实现各自的方法，然后注册到这个抽象层中去。这样对于上层应用而言并没有任何区别，因为上层只需调用抽象层接口就行了，不管底层硬件的差异性。AudioFlinger就是这样的一个抽象层，无论底层是ALSA设备还是BluetoothHeadset，上层都只会看到AudioFlinger的接口。至于何时切换到ALSA设备何时切换到BluetoothHeadset，这就属于音频策略调度范畴了即AudioPolicyService。