使用Cerence TTS/ASR时Android设备连接Bluetooth SCO音频丢失咨询

您好，我遇到了一个特定的技术问题，希望有相关经验的人员可以提供解决思路。
我目前正在使用Cerence提供的第三方TTS（文本转语音）和ASR（自动语音识别）库，在Android 12以及部分Android 11设备上同时使用这两个库时，会出现音频输出关闭的故障：ASR输入功能可正常使用，但无任何音频可以播放。
目前日志中未查询到太多相关报错信息，故障发生后需要断开蓝牙耳机重新连接才能恢复正常。
初步测试结果显示，Android 12设备启用Bluetooth SCO后很快就会出现音频丢失问题，相关调用代码如下：

AudioManager am = (AudioManager) context.getSystemService(Context.AUDIO_SERVICE);
// 需要设置模式，保证蓝牙耳机可以正常获取音频
am.setMode(AudioManager.MODE_IN_COMMUNICATION);
am.startBluetoothSco();

Android 11设备也存在同类问题，虽可稳定复现，但暂无精准的复现步骤。
想咨询以下问题：

1. 该类音频问题有什么调试方法？是否有特定的日志可以提取查看？故障发生时所有音频都无法播放，比如蓝牙耳机播放YouTube也无声音，推测要么音频被重定向到其他设备，要么音频模块已崩溃。
2. 除了Bluetooth SCO外是否有其他控制麦克风的方式？是否有其他效果不同的SCO设置可使用？

更新：更多测试发现，AudioManager的模式被未知进程从MODE_IN_COMMUNICATION修改为NORMAL，目前暂未找到修改原因，但持续强制将模式设置为MODE_IN_COMMUNICATION时，音频可正常播放。

1. 音频故障调试方法与日志提取 #

• 系统音频服务日志过滤：
  执行命令adb logcat -s AudioManager AudioService AudioPolicy可过滤出音频框架核心运行日志，所有AudioManager.setMode的调用都会被记录，且附带调用方的UID信息，通过adb shell pm list packages -U | grep [对应UID]即可定位到篡改音频模式的具体应用进程。
• 全量音频状态导出：
  故障发生时执行adb shell dumpsys audio，输出结果包含当前全局音频模式、活跃音频路由、SCO连接状态、AudioFlinger运行状态，可直接确认故障是路由重定向还是音频服务崩溃。如果是服务崩溃，结果中会明确显示AudioFlinger的重启记录。
• 蓝牙SCO连接日志排查：
  开启开发者选项中的「蓝牙HCI信息收集日志」，复现故障后提取/sdcard/btsnoop_hci.log可分析SCO链路的异常断开原因。

2. 麦克风控制替代方案与SCO参数优化 #

• 非SCO麦克风采集方案：
  如果你的业务场景不需要使用蓝牙耳机侧的麦克风输入，可直接调用系统AudioRecord接口采集设备自带麦克风的音频，无需启动Bluetooth SCO、也不需要将音频模式设置为MODE_IN_COMMUNICATION，音频输出走常规媒体流通道，可完全避免通信模式的抢占问题。
• SCO配置优化：
  你当前的SCO调用缺少必要的状态设置，可补充配置降低被系统或其他进程抢占的概率：

  AudioManager am = (AudioManager) context.getSystemService(Context.AUDIO_SERVICE);
  am.setMode(AudioManager.MODE_IN_COMMUNICATION);
  // 避免通信流被系统自动静音
  am.setStreamVolume(AudioManager.STREAM_VOICE_CALL, am.getStreamMaxVolume(AudioManager.STREAM_VOICE_CALL), 0);
  am.startBluetoothSco();
  // 显式开启SCO音频通路
  am.setBluetoothScoOn(true);
  

• 模式被篡改的修复方案：
  注册系统广播AudioManager.ACTION_AUDIO_MODE_CHANGED，收到广播后校验当前音频模式，如果你的ASR/TTS服务仍在运行、且当前模式不是MODE_IN_COMMUNICATION，立即强制重置为通信模式即可解决你发现的模式被篡改问题。

内容的提问来源于stack exchange，提问作者Brian S