android - VoIP 通话后 Android 通知无法以正确的音量播放

Question

我已经在原生 Android 应用程序中实现了 VoIP 呼叫，但我们发现了一个我被困住的错误。如果有帮助的话，我将使用 Twilio 进行 VoIP 通话。

如果我从我们的应用程序拨出VoIP 电话，在通话结束后，如果我将应用程序置于后台并收到通知，通知的音量大约是我拨打电话之前的一半。这不仅是来自我的应用程序的通知，而且其他应用程序也受到影响。如果我将我的应用程序从应用程序历史记录中滑出，使其不再在后台运行，则通知将返回以正确音量播放。

当我接到来电时不会发生这种情况，即使我已经验证相同的代码会断开呼叫连接，无论它是传入还是传出。

我已经验证，当通知进来时，设备的通知音量仍然使用 AudioManager 的getStreamVolume(AudioManager.STREAM_NOTIFICATION)API 一直调高。

由于似乎所有应用程序都受到了影响，而不仅仅是我自己的应用程序，我想我可以放心地假设问题不是播放通知声音的代码。我在想也许与 VoIP 通话有关的某些东西没有被正确释放，并且操作系统本身正在以较低的音量播放音调，因为它仍然认为我们正在通话，但我找不到任何证据.

我已经确认我Connection的调用对象是调用onDisconnect(), 和destroy()。我ConnectionService的也被破坏了。通知时的通话状态不是CALL_STATE_OFFHOOK根据TelephonyManager.

您还能想到其他什么会导致通知以降低的音量播放吗？

score 1 · Accepted Answer

我们在 VOIP 应用程序中也遇到了同样的问题，尽管在我们的案例中我们直接使用 webrtc 而不是 Twilio Video - 所以我不知道这是否完全适用于您的案例，但也许可以帮助您找到一些线索。

在我们的例子中，我们发现我们没有在所有 WebRTCPeer 对象上调用 close()。这意味着在通话结束后，AudioTrack 仍然处于活动状态，这会影响音频路由......导致非常安静的铃声/通知声音。

我猜想 Twilio Video SDK 的等价物是确保您取消发布和释放所有音轨（以及视频和数据轨道），然后断开 Room 对象。

我们发现了一些很好的线索来检查adb shell dumpsys audio- 在不良状态下的输出，我们可以在“流音量”部分看到用于响铃/警报/通知流的设备卡在“听筒”而不是“扬声器”上，并且在“播放器”部分中有一个额外的 AudioTrack。

也许这会给你一些尝试的想法……祝你好运！

1 回答 1