我有一个活动应用程序设置为使用自我管理的连接服务,因为我们正在使用音频和视频,并且希望能够利用系统。然而,关于我们关闭连接或可能更改音频流的方式的一些事情正在引起一个问题,我将尽我所能在这里描述。
当我开始我们的应用程序的通话时,一切都按照我们想要的方式工作,它在免提电话中启动,但对免提电话按钮的按钮按下反应良好,音频效果很好!然而,当通话结束时,我的手机陷入了一种模式,任何通知都不会通过扬声器播放,而是通过耳机播放,这意味着我所有的通知都相当安静。我认为这是因为我们没有正确地重置音频流。我不确定这是否意味着在Connection对象的破坏()中发生,或者更确切地说,在我们请求音频焦点等的活动中发生...下面是我认为是罪魁祸首的代码
此方法初始化音频是从单个活动的onResume()调用的。根据用户设备的构建版本,我们沿着两条不同的请求路径
private fun initializeAudio() {
if (!audioManager.isInCall()) {
volumeControlStream = AudioManager.STREAM_VOICE_CALL
// Request audio focus for playback
val result: Int = if (Build.VERSION.SDK_INT > Build.VERSION_CODES.O) {
audioManager.requestAudioFocus(focusRequest)
} else {
@Suppress("DEPRECATION")
audioManager.requestAudioFocus(
afChangeListener,
AudioManager.STREAM_VOICE_CALL,
AudioManager.AUDIOFOCUS_GAIN
)
}
if (result != AudioManager.AUDIOFOCUS_REQUEST_GRANTED) {
StreemLog.logError(TAG, "Audio focus request denied", sendBreadcrumb = true)
}
}
}
所以这是音频焦点对较新版本的要求
private val focusRequest: AudioFocusRequest by lazy {
if (Build.VERSION.SDK_INT > Build.VERSION_CODES.O) {
AudioFocusRequest.Builder(AudioManager.AUDIOFOCUS_GAIN).run {
setAudioAttributes(
AudioAttributes.Builder().run {
setLegacyStreamType(AudioManager.STREAM_VOICE_CALL)
setContentType(AudioAttributes.CONTENT_TYPE_SPEECH)
build()
}
)
setOnAudioFocusChangeListener(afChangeListener)
build()
}
} else throw IllegalStateException("Trying to use AudioFocusRequest below minimum API 26")
}
这是一个更为过时的OnAudioFocusChangeListener
private val afChangeListener: AudioManager.OnAudioFocusChangeListener =
AudioManager.OnAudioFocusChangeListener { focusChange ->
when (focusChange) {
AudioManager.AUDIOFOCUS_LOSS -> {
tearDownAudio()
}
AudioManager.AUDIOFOCUS_LOSS_TRANSIENT -> {
// noop
}
AudioManager.AUDIOFOCUS_LOSS_TRANSIENT_CAN_DUCK -> {
// noop
}
AudioManager.AUDIOFOCUS_GAIN -> {
initializeAudio()
}
}
}
最后,我们有我们的tearDownAudio()方法,该方法在活动中从onPance()调用
private fun tearDownAudio() {
volumeControlStream = AudioManager.USE_DEFAULT_STREAM_TYPE
if (Build.VERSION.SDK_INT > Build.VERSION_CODES.O) {
audioManager.abandonAudioFocusRequest(focusRequest)
} else {
@Suppress("DEPRECATION")
audioManager.abandonAudioFocus(afChangeListener)
}
}
我猜问题出在tearDownAudio()方法的某个地方,因为设备上的音频在开始和通话过程中工作得很好,但在通话结束后没有返回到正常流。
问题也可能存在于ConnectionService实现中,因为我们正在使用自我管理的连接服务,但是我的第一直觉是上面的代码就是问题所在。
我的一位团队成员发现了这个问题!经过大量的调试...
当呼叫结束时,我们只关闭了本地参与者的WebRTCPeer连接,而不是所有参与者。所以只剩下一个WebRtcAudioTrack对象在运行。对它们调用close会释放音频资源,并且所有流路由都会恢复到正确的状态。
所以,这个故事的寓意是确保在结束通话时关闭所有连接!