1. 理解Android多应用录音的困境想象一下这样的场景你正在开发一款直播助手应用需要同时录制系统声音和麦克风输入。这时候用户突然想用另一个录音应用记录会议内容结果你的应用立刻收不到音频数据了。这就是Android 10引入的音频策略服务AudioPolicyService在作怪。我去年就踩过这个坑。当时给客户做车载语音助手需要同时处理导航语音和音乐播放结果发现只要打开Google Assistant其他录音应用立刻变成聋子。经过反复调试才发现从Android 10开始系统通过UidPolicy给每个应用打上了录音权限标签就像给每个学生发不同颜色的校服门卫AudioPolicyService只放行穿特定颜色校服的学生。关键问题出在isVirtualSource这个判断逻辑上。系统默认只允许虚拟音频源如语音识别、通话录音进行多路录音普通录音应用会被强制互斥。这就像音乐厅只允许持VIP票的观众从多个入口进场普通票观众必须排队走同一个门。2. 解剖AudioPolicyService的工作机制2.1 UidPolicy的权限管控体系AudioPolicyService相当于音频系统的交通警察它通过UidPolicy管理着所有应用的录音权限。每个应用启动录音时系统会调用这个流程// 简化后的调用链 AudioRecord.startRecording() → AudioPolicyService::startInput() → UidPolicy::updateUid() → AudioPolicyManager::setAppState()核心控制点在AudioPolicyService.cpp的这段代码bool AudioPolicyService::isVirtualSource(audio_source_t source) { switch (source) { case AUDIO_SOURCE_VOICE_UPLINK: case AUDIO_SOURCE_VOICE_DOWNLINK: //...其他虚拟源类型 default: return false; // 普通录音源返回false } }当两个普通录音应用同时运行时后启动的应用会触发前一个应用的APP_STATE_IDLE状态就像音乐播放器遇到来电自动暂停一样。2.2 实际开发中的典型症状在日志中你会看到这样的线索W/AudioPolicy: startInput() return ERROR_INVALID_OPERATION E/AudioRecord: start() status -38这就像系统在说抱歉这个麦克风已经被占用了。我遇到过最棘手的情况是某些厂商ROM会修改默认策略导致相同代码在不同设备表现不一。比如华为EMUI就曾对语音助手类应用有特殊白名单。3. 实战修改系统策略3.1 定位关键修改点我们需要在frameworks/av/services/audiopolicy/service/AudioPolicyService.cpp中找到isVirtualSource函数。原始代码就像个严格的安检员只放行特定类型的音频源/* static */ bool AudioPolicyService::isVirtualSource(audio_source_t source) { switch (source) { case AUDIO_SOURCE_VOICE_UPLINK: // 上行语音 case AUDIO_SOURCE_VOICE_DOWNLINK: // 下行语音 case AUDIO_SOURCE_VOICE_CALL: // 通话 case AUDIO_SOURCE_REMOTE_SUBMIX: // 远程混音 case AUDIO_SOURCE_FM_TUNER: // 收音机 case AUDIO_SOURCE_VOICE_RECOGNITION: // 语音识别 return true; default: break; } return false; }3.2 添加自定义音频源类型假设我们要支持普通麦克风录音的多路复用可以这样修改/* static */ bool AudioPolicyService::isVirtualSource(audio_source_t source) { switch (source) { // 保留原有虚拟源 case AUDIO_SOURCE_VOICE_UPLINK: //...其他系统保留类型 // 新增自定义类型 case AUDIO_SOURCE_MIC: case AUDIO_SOURCE_CAMCORDER: return true; // 将这些普通源也视为虚拟源 default: break; } return false; }注意不同Android版本可能有差异Android 9及之前需要修改AudioPolicyManagerBase.cppAndroid 10集中在AudioPolicyService.cpp3.3 编译刷机验证修改后需要重新编译framework模块mmm frameworks/av/services/audiopolicy/ make snod # 重新生成system.img验证时建议使用以下命令监控音频策略变化adb shell dumpsys media.audio_policy4. 替代方案与优化建议4.1 非Root方案音频路由技巧如果无法修改系统代码可以尝试这些方法使用REMOTE_SUBMIX虚拟设备通过AudioRecord.setPreferredDevice()指定不同设备创建虚拟输入源混流但实测这些方法都有局限比如延迟增加、兼容性问题等。我在小米设备上就遇到过REMOTE_SUBMIX被厂商禁用的情况。4.2 性能优化要点多路录音时要特别注意采样率必须一致建议用48kHz缓冲区大小需要调整避免连续创建多个AudioRecord实例典型的参数配置示例int bufferSize AudioRecord.getMinBufferSize(48000, AudioFormat.CHANNEL_IN_MONO, AudioFormat.ENCODING_PCM_16BIT) * 2; AudioRecord record new AudioRecord( MediaRecorder.AudioSource.MIC, 48000, AudioFormat.CHANNEL_IN_MONO, AudioFormat.ENCODING_PCM_16BIT, bufferSize);5. 深入原理音频策略的演进Android的音频策略管理经历了几个关键阶段版本特性多应用录音支持4.4初步引入AudioPolicy需要手动修改mixer_paths.xml5.0引入AudioPolicyManager支持有限的多路录音8.0动态权限控制增强开始限制后台录音10.0UidPolicy强化默认禁止普通应用多路录音这种演进反映出Google在隐私保护和功能灵活性之间的平衡。理解这个背景很重要就像知道交通规则变化的历史才能更好地规避违章。在车载系统开发中我们最终采用的方案是修改isVirtualSource允许特定包名多路录音增加音频焦点冲突处理回调使用反射绕过某些厂商限制这些经验说明面对Android音频系统的限制需要结合具体场景选择最适合的破解之道。
