Nexus 5 装上 Ubuntu 后想实现“同时接听来电 去电”很多人第一反应是去通话界面找“添加通话”按钮。等真开始折腾就会发现这个功能不是按钮问题而是整个电话栈的能力问题系统能不能在保持当前通话的同时新建第二路通话。这篇文章按实际排查顺序整理出来包含环境要求、默认失败原因、验证步骤、修改方向和容易忽略的边界适合正在折腾 Ubuntu Touch 电话功能的人也适合想理解 oFono、RIL、调制解调器三者配合的开发者。1. 这个功能卡在哪一层UI、呼叫管理还是调制解调器1.1 用户在界面上看到的是按钮系统背后走的是一整套呼叫流程“同时接听来电 去电”在普通 Android 手机上很常见你先接通 A 的电话再拨给 BA 会被保持B 接通后你可以切换来回。这个过程中用户只看到通话界面里多了“保持”“添加通话”“切换”几个选项。但在 Ubuntu Touch 这类移动 Linux 系统里事情要分三层看最上层是电话 UI 和通话应用负责画界面、响应用户点击。中间是呼叫控制服务Ubuntu Touch 里通常基于 oFono负责管理当前正在进行的通话对象决定是否允许保持、合并、新建。最底层是调制解调器也就是硬件基带它直接跟运营商网络协商通话能力。“同时接听来电 去电”要成立三层都要支持。UI 只是最后一步真正决定功能可用性的是中间层有没有把“保持一路通话”和“新建第二路通话”这两个操作正确下发以及底层调制解调器有没有返回成功。所以排查时不要盯着界面看。界面看不到按钮不代表系统不支持界面有按钮也不代表真的能跑通。1.2 为什么 Nexus 5 是这个场景里最常被提到的设备Nexus 5 是 2013 年发布的设备硬件开放程度高bootloader 可以解锁刷机资料齐全。Ubuntu Touch 社区长期把它作为官方支持设备之一很多镜像都围绕 Nexus 5 做兼容测试。它还有一个容易被人忽略的优点硬件方案来自高通调制解调器对 RIL 指令的兼容性通常比一些冷门机型好。RIL 层如果能把底层能力透传上来上层 oFono 才有机会实现多路通话。但“兼容性好”不等于“默认就能跑通”。同一个机型的基带版本、系统镜像、运营商网络都存在差异所以标题里的“同时接听来电 去电”在不同人手里会得到完全不同的结果。正确做法是先确认自己手上设备的基带、镜像版本和电话栈状态再开始验证。2. 运行镜像、语音链路和调试工具先对齐这些前提2.1 系统层面需要满足的条件我建议你先确认三样东西当前刷入的 Ubuntu Touch 镜像版本。当前 Nexus 5 的基带版本。是否已经解锁 bootloader能否通过 SSH 或 ADB 进入系统并查看日志。镜像是关键。不同版本内置的 oFono、rilmodem 插件、上层电话服务版本都不一样。某些较老的镜像可能在单路通话上都有问题更不用说多路呼叫。还要注意一个现实问题不是所有 Nexus 5 刷机后的状态都一样。有人刷完能识别 SIM 卡有人需要手动设置 APN有人 LTE 不可用。如果系统连基本移动网络都不稳定直接测“同时接听 去电”没有意义。2.2 语音通话链路里的三个关键部件为了后面排查看得懂日志这里把链路简化成一张表层级对应组件主要作用调制解调器Nexus 5 内置基带负责信号处理、语音编解码、网络协商用户空间 RILAndroid RIL 用户态库把基带能力翻译成 RIL 请求呼叫控制服务oFono配合 rilmodem 插件管理通话状态、暴露接口给上层 UIUbuntu Touch 不会直接用 Android 那套 Java 电话栈而是用 oFono 统一处理通话、短信、网络注册等。oFono 通过 rilmodem 插件和 Android RIL 通信最终指令才到达基带。这个设计有一个好处同一套 oFono 可以适配多款设备。代价是每款设备的 RIL 能力不同oFono 只能使用 RIL 能提供的部分。2.3 调试工具和连接方式在 Ubuntu Touch 设备上我一般先开开发者模式然后用 SSH 连进去。手机和电脑连同一个网络拿到的 IP 能固定就固定方便反复测试。用到的工具主要这些journalctl -u ofono -f实时查看 oFono 日志。ofonoctl或mmcli查看 modem 状态、通话对象、网络注册情况。adb shell如果镜像保留了 ADB 通道也可以直接进去。cat /proc/cmdline确认系统启动参数。这些命令不一定每个镜像都齐全缺哪个就先装哪个或者用系统自带的管理器查看。核心原则是所有测试都要有日志可回看。没有日志就无法判断失败发生在 UI、oFono 还是基带。3. 默认系统为什么很难做到“同时接听 去电”3.1 oFono 的呼叫模型里单路和多路是两套能力oFono 会把每一通通话抽象成一个voice call对象。单路通话只需要Dial、Answer、Hangup这类基础操作。但要想在接听 A 的同时再拨给 B系统必须额外支持Hold保持当前通话。Swap在两个通话之间切换。Conference把多路通话合并。ReleaseAndAnswer挂断一路后接听另一路。如果系统里 oFono 的 VoiceCallManager 没有注册这些操作上层 UI 无论怎么做都不会出现“添加通话”入口。即便出现了点击之后也没有实际动作。这不是 UI 能绕过去的问题是底层能力就没暴露出来。3.2 rilmodem 到底有没有把多路呼叫透传上来rilmodem 是 oFono 和 Android RIL 之间的桥梁。它虽然叫“RIL modem”但并不是所有 RIL 请求都会原样转发给基带。Nexus 5 的厂商 RIL 是否实现“呼叫保持”“呼叫等待”“第二路呼出”这些请求直接决定结果。有的镜像为了稳定可能在编译 oFono 或 rilmodem 时关闭了部分特性有的镜像则保留了完整通话能力只是上层应用没显示入口。这就导致同一个机型经常出现两种完全不同的表现现象最可能的原因界面根本没有“添加通话”按钮上层服务认为设备不支持多路呼叫有按钮点击后无反应oFono 的 VoiceCallManager 缺少对应操作拨出第二路时第一路被挂断rilmodem 把第二个 Dial 当成新的独立呼叫来电时不提示呼叫等待该 feature 未启用或网络侧不支持看到“拨出第二路时第一路被挂断”这种表现很多人以为是 bug其实很多时候是底层根本没有保持能力。3.3 运营商网络和 SIM 套餐也要计算在内设备能力只是必要条件不是充分条件。多路通话需要网络侧协同。3G/2G 网络下呼叫等待和多方通话通常由电路域协商。4G VoLTE 下则依赖 IMS 网络能力。两者逻辑不同终端显示的结果也会不同。更麻烦的是运营商侧限制。有些套餐没有开通“呼叫等待”或者不开放“多方通话”终端就算能力完整也会被网络拒绝。遇到这种情况换多少镜像都没用。所以排查顺序应该是先确认自己的 SIM 卡套餐是否支持呼叫等待和多方通话再测试设备能力最后才怀疑镜像和 RIL 的问题。4. 两轮验证先测单路再测多路最后看日志4.1 测试前的准备清单我用两台辅助手机来做测试手机 A作为被叫方也可以主动呼叫 Nexus 5。手机 B作为第二路通话对象。Nexus 5被测设备运行 Ubuntu Touch。测试前先把 oFono 日志输出到文件避免操作过程中忘了看细节。示例journalctl -u ofono -f /tmp/ofono-test.log 这一步很重要。后面不管是自己看还是把问题反馈给社区日志都是最直接的证据。4.2 第一轮单路来电和单路去电先不要碰多路。用手机 A 呼叫 Nexus 5接听后确认双向语音正常。挂断后再从 Nexus 5 主动拨出给手机 A确认对方能听到声音自己能听到对方声音。这轮通过的标准是来电能接听。去电能拨出。双方都能听到语音。日志里能看到dial、answer、hangup等事件。如果单路都不稳定后面不用继续。单路有问题通常意味着调制解调器识别、音频路由或信号注册存在基础问题。4.3 第二轮模拟“接听后再拨第二路”的完整操作这轮就是标题要解决的核心场景。操作顺序手机 A 呼叫 Nexus 5。Nexus 5 接听。Nexus 5 保持通话通过拨号盘拨出手机 B 的号码。观察手机 B 是否收到来电A 是否被保持。会出现三种结果结果一B 正常响铃A 进入保持状态。说明底层支持保持和新第二路呼出问题已经解决大半。结果二A 被挂断B 拨通。说明系统把第二路呼出当成新的独立呼叫没有做保持底层缺少HOLD能力。结果三拨号盘无法操作或者界面上根本没有拨号入口。说明上层 UI 在通话中锁定问题更多在上层服务。不管哪个结果都要回过去对日志。4.4 通过日志判断失败点日志里重点找这几个信号点击拨号后有没有出现Dial请求。请求有没有被 oFono 接受还是直接返回错误。日志中有没有HOLD、SWAP、RELEASE_ANSWER之类的字段。有没有RIL_E_NOT_SUPPORTED或REQUEST_NOT_SUPPORTED这类返回。如果发现Dial请求根本没有发出去问题大概率在上层 UI 或 oFono 配置。如果请求发出去了但 RIL 返回不支持那就是厂商 RIL 或基带能力的限制。这一步能把问题边界划得很清楚。后面不管怎么改都先在日志里找证据。5. 可行的修改方向补丁、配置、组件替换与换镜像5.1 先查 oFono 和 rilmodem 的版本再去社区找补丁Nexus 5 的 Ubuntu Touch 镜像里oFono 的 rilmodem 插件通常是二进制包。直接改它不太现实常见做法是从源码重新编译带补丁的 oFono 版本。但编译前一定要弄清楚当前镜像里 oFono 的版本号。这个可以看日志也可以查包管理器。命令不唯一但目标一致拿到版本号去社区 issue 或提交记录里搜索multi call、hold、conference、rilmodem这些关键词。有些问题已经不是新问题社区可能已经有人提过补丁只是某些镜像没有合进去。找到对应补丁再评估自己有没有能力编译和替换。5.2 检查 oFono 配置和启动参数有些镜像中部分通话特性在 oFono 启动时就被禁用了。可以看看/etc/ofono下有没有配置文件或者进程启动参数里有没有特殊选项。不过这里要提醒一句不是所有能力都能靠配置打开。如果 rilmodem 插件编译时就没有包含某个功能配置里写再多也没有用。更稳妥的方式是先用ofonoctl或mmcli看看当前 modem 暴露了哪些能力。比如有些工具可以直接列出设备支持的呼叫特性。如果列表里缺了“hold”和“conference”说明多半是底层就没暴露。5.3 替换上层电话应用验证到底是 UI 问题还是底层问题如果底层已经支持多路只是界面没有入口那就很值得继续折腾。可以在命令行里用工具直接操作通话模拟“保持当前通话再拨出第二路”的行为。这一步能验证两件关键事情oFono 是否接受第二个Dial。第一路通话是否进入保持状态。如果命令行操作成功问题就在上层电话应用或 UI 服务修 UI 比改底层轻松很多。如果命令行操作也失败那就要回到 oFono 和 rilmodem 那一层去查。5.4 实在不行考虑换一个更接近社区新版本的镜像Ubuntu Touch 社区还在持续维护新 OTA 版本通常会修复一批和 RIL 相关的问题。但换镜像不是万能药要提前想清楚代价老数据可能不兼容。新版本可能引入新的音频或网络问题。需要重新测试基础功能如短信、网络、定位。我一直建议换镜像前先把当前版本的日志和复现步骤整理好。这样即使换完仍然失败也可以拿着资料去社区反馈。盲目刷机很可能刷了一圈还是回到原点。6. 测试中容易忽略的边界条件基带、网络制式与音频路由6.1 基带版本和硬件批次会影响结果Nexus 5 在出厂后有过多次系统更新基带固件版本也不完全一样。Ubuntu Touch 镜像可能只更新内核和用户空间不一定会更新基带。基带和 RIL 版本不匹配时表面上能识别 SIM 卡、能打电话但一旦触发多路呼叫就可能出现异常。所以测试前先记录基带版本不要随意刷别的基带除非明确知道兼容。如果同一台设备在某个基带版本下能保持通话换版本后反而失败先不要怀疑 oFono优先回退基带。6.2 单卡、双卡、VoLTE 和网络制式的差异Nexus 5 标准版是单卡设备这和后来一些双卡机器不一样。单卡下多路通话完全依赖网络侧能力和调制解调器对呼叫等待的配合。4G VoLTE 环境下通话保持和多方通话要经过 IMS 网络协商Ubuntu Touch 对 VoLTE 的支持不一定完整。如果当前镜像的 IMS 栈本身就不稳定那“同时接听 去电”的失败可能根本和 oFono 没有关系。更稳妥的测试方法是把网络切到 3G 或 2G重新跑一遍多路通话。如果 3G 下正常、4G 下失败那问题更可能出在 VoLTE 相关能力而不是多路呼叫逻辑本身。6.3 音频路由、蓝牙耳机和通话并发的干扰多路通话测试里音频路由很关键。蓝牙耳机的音频走 HFP 协议如果 HFP 连接不稳定可能造成“对方听不见你”或“你听不见对方”但日志里通话状态是正常的。我建议测试时先用手机自带听筒再试扬声器。确认音频正常后再开蓝牙设备测试。这样可以把音频路由问题从通话状态问题中剥离出来。否则很容易出现一个假象通话状态已经切到第二路但因为没有声音你误以为功能没生效。6.4 修改和测试前养成留日志的好习惯移动 Linux 调试里最重要的不是灵光一闪而是可复现的记录。每次改动前我都建议记录当前镜像版本。oFono 版本。rilmodem 插件版本。基带版本。测试时间点和操作步骤。然后在每一步操作后在日志文件里加入一个时间标记。比如date /tmp/ofono-test.log回头排查时直接看对应时间窗口的日志能省掉大量重复测试。7. 我的结论与后续值得继续尝试的路线7.1 先判断这个功能到底值不值得继续折腾如果只是日常使用通话场景主要是单路呼入呼出那“同时接听 去电”并不是必须功能。默认镜像哪怕不支持也可以继续正常使用。如果你需要用它做移动开发测试或者想长期用 Ubuntu Touch 当主力机的一部分那就值得继续深挖。因为多路通话是否支持直接反映当前设备电话栈的完整度。我的判断标准很简单单路通话稳定值得继续折腾多路。单路通话本身就不稳定先把基础问题解决。底层日志明确返回不支持优先找补丁或换镜像。底层命令能跑通只是 UI 没入口优先修上层。7.2 如果要继续我建议按这个顺序推进第一步把当前镜像的所有日志保存下来尤其是 oFono 日志。第二步用命令行工具确认 oFono 是否支持保持、交换、合并。不要一开始就编译源码。第三步如果命令行能力不足再找对应 oFono 版本和 rilmodem 的补丁评估编译成本。第四步测试 3G/2G 和 VoLTE 两种网络环境区分网络侧差异。第五步有结果后去社区反馈附上基带版本、镜像版本、完整日志和操作步骤。这五步走完不管最终能不能实现你对 Nexus 5 的语音链路、oFono 的呼叫管理和 RIL 的边界都会有一个非常清晰的理解。这也算折腾 Ubuntu Touch 过程中最值得沉淀的部分。7.3 最后留一个实战提醒不要为了“同时接听来电 去电”这个单一功能反复刷不同镜像而不做记录。移动 Linux 系统里一个功能涉及的链路太长没有日志和版本记录任何排查都会变成碰运气。先把基础环境稳住再针对多路通话去做验证和补丁。这样即使最后没有跑到目标你也留下了一套可以复用的排查方法。下次换到别的设备、别的系统同样能派上用场。