Pixel 7 Pro + 中国电信：从“有数据却没语音”到恢复 VoLTE

· 阅读约 11 分钟

#pixel#android#adb#carrierconfig#ims#volte#troubleshooting

这次问题不是 Wi-Fi，也不是 APN。

在中国旅行时，我把一张中国电信 SIM 卡插入 Pixel 7 Pro。手机能显示运营商名称，移动数据也能用，但电话功能不正常。与此同时，信号只有 2/4 格，RSRP 大约 -110 dBm，很容易让人把问题归结为“信号太差”。

但 ADB 里的证据并不是这样写的：数据域已经正常注册，语音域却离线，IMS 也没有建立注册。最终定位到的根因是：这台 Pixel 对中国电信这张 SIM 的 CarrierConfig 没有启用 VoLTE 能力。

本文记录的是我自己设备上的非破坏性排查和修复。不同 Pixel 型号、系统版本、运营商组合可能不同；请不要直接用这段经历替代运营商侧的实网诊断。

TL;DR

  • 现象：LTE 数据可用，但语音无服务，IMS 未注册。
  • 关键证据：数据域为 HOME，语音域为 NOT_REG_OR_SEARCHING；LTE_VOICE_CAPABLE=false。
  • 根因：Pixel 的运营商配置没有对中国电信 46011 启用 VoLTE。
  • 修复：使用 TensorIMS 的 Embedded Shizuku + USB ADB 后端，只覆盖启用 VoLTE，再开启持久 VoLTE。
  • 验证：修复后 IMS Registered、VoLTE Available；重启后仍有效；关闭 Wi-Fi 仅用电信 LTE 也能正常联网。
  • 没有做的事：没有改 APN、基带、EFS 或分区，没有 root，也没有用来源不明的 Magisk 模块。

先别被 Travel 卡片带偏

排查初期，我还看过 Pixel At a Glance 里的 Travel 提示。它看起来像是一个与旅行、网络或当前地点有关的功能，但它只是上层展示，不是 SIM 卡能不能打电话的原因。

真正能把问题说清楚的是蜂窝栈：

  • 数据是不是已经注册？
  • 语音域有没有服务？
  • VoLTE 能力有没有被平台打开？
  • IMS 有没有发起注册？

把注意力从 UI 卡片移回 telephony 和 IMS 之后，证据很快就一致了。

问题现场

当时的设备状态如下：

项目 状态

这里最值得注意的不是“电话打不通”，而是数据正常和语音异常可以同时发生。

数据正常，不等于语音正常

移动数据主要看 PS 域、APN 和 LTE 承载；VoLTE 语音则多了一条 IMS 路径。两条路径共享蜂窝信号，但注册状态、APN 和 IMS 能力并不共享。

可以把这次的数据路径和语音路径画成这样：

中国电信在 LTE 场景下需要通过 VoLTE 承载语音。Pixel 侧如果没有把这张 SIM 的 VoLTE 能力打开，系统就不会尝试走正常的 IMS 注册路径。结果是：

  • 手机仍然能通过 LTE 上网；
  • 信号格还能显示；
  • 但语音服务不可用。

所以，“有信号”不等于“能打电话”。信号格描述的是无线链路质量，不描述 IMS 是否注册成功。

证据链

我通过 USB ADB 读取设备状态。下面命令里的 adb 替换成自己电脑上的路径即可：

bash
adb devices -l
adb shell dumpsys telephony.registry

当时的关键状态是：

text
mVoiceRegState=OUT_OF_SERVICE
mDataRegState=IN_SERVICE
CS  -> NOT_REG_OR_SEARCHING
PS  -> HOME
mDataConnectionState=2

这已经说明数据链路和语音链路被分开了：PS 域正常，CS/语音侧没有服务。

接下来检查 IMS：

bash
adb shell dumpsys activity service com.shannon.imsservice/.ShannonImsService

修复前的几个关键字段：

text
LTE_VOICE_CAPABLE=false
Provision-enabled=false
VOLTE_ENABLED_BY_PLATFORM=0
VOICE_OVER_LTE=0
IMS Regi History: 空

这组状态把问题范围收窄到了 CarrierConfig / VoLTE capability，而不是 APN 配错或单纯的弱信号。

为什么弱信号不是根因

当时的 RSRP 确实偏低，大约 -110 dBm，而且只在 Band 5、10 MHz 上工作。但同一时刻：

  • LTE 数据是 IN_SERVICE；
  • ctlte APN 是 CONNECTED；
  • 互联网请求能正常完成；
  • 修复 VoLTE 后，在相同的弱信号下 IMS 仍然注册成功。

弱信号会影响质量和稳定性，但不会解释“数据完全可用、语音域却完全没有尝试 IMS 注册”这个组合。

为什么不先改 APN 或刷基带

APN 已经连接，数据链路也正常；此时继续改 APN 很容易把原本正常的数据路径也弄坏。

设备还是 locked bootloader、user build，没有 root。为了一个 CarrierConfig 能力开关去解锁、刷模块，风险和收益完全不成比例。更稳妥的做法是先用最小的、可回滚的方式改变运营商配置。

修复方案

我使用的是 TensorIMS 4.0.1.r228。它面向 Pixel Tensor 设备，支持通过 Shizuku 或电脑 ADB 启动私有后端，用 shell 级权限写入 CarrierConfig 覆盖。

项目地址：Pixel-Tailor-CN/TensorIMS

1. 安装并选择 Embedded Shizuku

安装 APK 后，在权限模式里选择：

text
Embedded Shizuku

这里没有使用 Root，也没有额外安装一个需要长期运行的 Shizuku App。

2. 用电脑 ADB 启动私有后端

在 TensorIMS 中选择：

text
Start via computer ADB
→ Generate start command

应用会生成一条类似下面的命令：

bash
adb shell /data/app/.../lib/arm64/libtensorims_starter.so --user 0

路径会随着应用版本变化，所以应以应用当次生成的命令为准。执行时保持 TensorIMS 在前台，并注意页面提示的短启动窗口。

后端连接成功后，页面会从 Disconnected 变成 Ready。

3. 只打开 VoLTE

进入中国电信 SIM 的 IMS 配置，我只启用 VoLTE：

  • VoLTE：开启；
  • VoWiFi：保持关闭；
  • VoNR：保持关闭；
  • VT：保持关闭。

然后点击 Apply changes。应用返回：

text
Applied and verified by reading back

这一步很重要。只看到界面开关变绿不算完成，必须确认配置真的被系统读回。

4. 开启持久 VoLTE

CarrierConfig 覆盖本身不应被当成永久状态。为了验证重启后的行为，我继续进入 Advanced tools，开启了：

text
Persistent VoLTE (Experimental)

开启后页面显示：

text
VoLTE opt-in: Yes
VoLTE user setting: Yes
IMS registered (snapshot): Yes

这个功能在应用里标注为 Experimental。我之所以使用它，是因为需要在旅行期间减少每次重启后再次连电脑修复的概率；同时也做了后续的重启实测，而不是只相信界面文案。

修复后的结果

启用 VoLTE 后，Shannon IMS 先短暂关闭，再重新启动，随后出现 IMS PDN 注册。关键字段变成：

字段 修复前 修复后

TensorIMS 的 IMS 状态页也显示：

text
IMS: Registered
VoLTE: Available

需要说明的是，dumpsys 里仍能看到 Provision-enabled=false。在这个实现里，它并没有阻止 IMS 注册成功，所以不能只拿单个字段做成败判断。最终应以“语音域是否可用、IMS 是否注册、实网是否能通话”为准。

重启验证

只验证一次运行时状态不够，因为临时 CarrierConfig 覆盖可能在重启后消失。所以我做了一次受控重启。

重启后有一个小插曲：USB 调试授权被重置，设备变成了 unauthorized。在手机上重新确认调试授权后，我继续做验证。

关键点是：此时 TensorIMS 进程并没有运行。

在这些条件下，设备状态仍然是：

text
mVoiceRegState=IN_SERVICE
mDataRegState=IN_SERVICE
mOperatorAlphaLong=China Telecom
LTE_VOICE_CAPABLE=true
VOICE_OVER_LTE=1
VOLTE_ENABLED_BY_PLATFORM=1
mLastRegisteredPlmn=46011

之后我再启动 TensorIMS 后端查询 UI 快照，页面显示：

text
IMS: Registered
VoLTE: Available

这比“应用还在运行时 IMS 正常”更有说服力：持久 VoLTE 确实在重启后保住了必要的语音能力。

LTE-only 复测

最后，我做了一次只依赖蜂窝网络的检查：

  1. 关闭 Wi-Fi；
  2. 等待 LTE 数据稳定；
  3. ping 223.5.5.5；
  4. 检查 IMS/VoLTE 字段；
  5. 恢复 Wi-Fi。

结果是 1 packets transmitted, 1 received, 0% packet loss，同时 VOICE_OVER_LTE、VOLTE_ENABLED_BY_PLATFORM 和 LTE_VOICE_CAPABLE 都保持正常。

这一步不能替代真实通话，但它至少证明：数据连接不是 Wi-Fi 回落，VoLTE 也不依赖 Wi-Fi。

你现在应该怎么验证

修复完成后，建议用普通号码做两次实际测试：

  1. 主动拨打一个常用号码，确认能建立通话并且双方有声音；
  2. 让对方回拨，确认能正常响铃和接听；
  3. 收发一条普通短信。

不要用紧急号码做功能测试。

如果通话仍然失败，先看两件事：

  • dumpsys telephony.registry 里语音域是不是 IN_SERVICE；
  • TensorIMS 的 IMS 状态是不是 Registered。

如果 IMS 正常但通话仍失败，再继续检查运营商侧的开通状态、VoLTE 权限和实际无线覆盖。不要把已经正常的 APN 和基带当成默认故障点。

回滚与维护

这次修复有几个维护要点：

  • 暂时不要卸载 TensorIMS，也不要清除它的应用数据；
  • 如果确实要卸载，先在 Advanced tools 里执行 Restore original settings；
  • 系统 OTA 或运营商配置更新后，重新检查 LTE_VOICE_CAPABLE 和 IMS 注册；
  • 如果以后换回其他运营商 SIM，先在应用里恢复原始配置，再做新的测试；
  • TensorIMS 是第三方实验性工具，使用前应确认版本、设备兼容性和风险。

复盘

这次问题最容易误判的地方，是“手机有信号、数据也能用”。但从系统角度看，数据域、语音域和 IMS 注册是三件不同的事：

  • 信号格只说明无线链路；
  • 数据注册只说明 PS 承载；
  • VoLTE 通话还需要 CarrierConfig 开放能力、IMS PDN 建立和 IMS 注册成功。

所以排查顺序应该是：先建立证据链，再改配置；先做最小覆盖，再验证重启；最后再谈持久化和回滚。

这次没有重装系统，没有刷基带，也没有改 APN。真正需要的只是一个正确的 CarrierConfig 能力开关，以及足够的验证来证明它确实生效。

相关文章

Comments

← macOS 26 点了 Stop Extending 后外接显示器黑屏：一次 WindowServer IndependentOutput 排障