Pixel 7 Pro + China Telecom: Why Data Worked but Calls Did Not, and How I Restored VoLTE

This was not a Wi-Fi problem, and it was not an APN problem.

While travelling in China, I inserted a China Telecom SIM into a Pixel 7 Pro. The phone showed the carrier name and mobile data worked, but calls did not. The signal was only two bars out of four and RSRP was around -110 dBm, which makes “the signal is simply too weak” look like a convincing explanation.

The ADB evidence said otherwise. Packet-switched data was registered, the voice side was out of service, and IMS had never registered. The root cause was that this Pixel’s carrier configuration did not enable VoLTE for the China Telecom SIM.

This is a record of a non-destructive repair on my own device. Different Pixel models, Android versions, carriers, and SIM profiles can behave differently. Do not treat this as a substitute for carrier-side diagnosis.

TL;DR

• Symptom: LTE data worked, but voice was unavailable and IMS was not registered.
• Evidence: Packet-switched data was HOME, while the voice side was NOT_REG_OR_SEARCHING; LTE_VOICE_CAPABLE=false.
• Root cause: The Pixel carrier configuration did not enable VoLTE for China Telecom 46011.
• Fix: Used TensorIMS with its Embedded Shizuku backend over USB ADB, enabled only VoLTE, then enabled persistent VoLTE.
• Verification: IMS Registered and VoLTE Available; the state survived a reboot; LTE-only connectivity was tested with Wi-Fi disabled.
• What I did not change: No APN, baseband, EFS, or partition changes. No root and no unknown Magisk module.

Do not let the Travel card mislead you

Early in the investigation I looked at the Travel card in Pixel At a Glance. It looked relevant because the phone was travelling, but it is only a UI surface. It does not determine whether a SIM can make phone calls.

The useful questions are in the cellular stack:

• Is packet-switched data registered?
• Is the voice side in service?
• Has the platform enabled VoLTE capability?
• Has IMS started registering?

Once I moved the investigation from the UI card to telephony and IMS, the evidence told a single, consistent story.

The initial state

Item	State

The important detail is not merely “calls failed.” It is that data worked while voice did not.

Data and voice are separate paths

Mobile data depends on the packet-switched domain, an APN, and LTE bearers. VoLTE voice has an additional IMS path. Both use the same radio signal, but their registration state, APNs, and IMS capabilities are independent.

On LTE, China Telecom needs a VoLTE path for voice. If the Pixel does not expose the SIM’s VoLTE capability, the system never follows the normal IMS registration path. The result is:

• LTE data still works;
• the signal bars still appear;
• voice service is unavailable.

“Signal” is not the same thing as “IMS registered.” The bars describe the radio link, not whether the voice service completed its own registration.

Evidence chain

I used USB ADB to inspect the phone:

bashCopy
adb devices -l
adb shell dumpsys telephony.registry

The relevant state was:

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

That already separates the working data path from the broken voice path: packet-switched data was healthy, while the voice side had no service.

Then I inspected IMS:

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

The important fields before the repair were:

textCopy
LTE_VOICE_CAPABLE=false
Provision-enabled=false
VOLTE_ENABLED_BY_PLATFORM=0
VOICE_OVER_LTE=0
IMS Regi History: empty

This narrowed the problem to CarrierConfig / VoLTE capability rather than a bad APN or ordinary weak coverage.

Weak signal was not the root cause

The RSRP was low, about -110 dBm, on Band 5 with a 10 MHz channel. At the same time:

• LTE data was IN_SERVICE;
• the ctlte APN was CONNECTED;
• internet requests worked;
• after VoLTE was configured, IMS registered successfully on the same weak signal.

Weak coverage affects quality and stability, but it does not explain the combination of “data is fully usable” and “the voice side never even tries to register with IMS.”

Why I did not change the APN or flash a baseband

The APN was connected and the data path was healthy. Changing it at that point would only risk breaking something that already worked.

The phone had a locked bootloader, a user build, and no root. Unlocking it or installing a module for one CarrierConfig capability switch would carry far more risk than the change was worth. A smaller, reversible configuration change was the better first move.

The fix

I used TensorIMS 4.0.1.r228. It targets Pixel Tensor devices and can start a private backend through Shizuku or computer ADB, allowing a shell-level CarrierConfig override.

Project: Pixel-Tailor-CN/TensorIMS

1. Install and select Embedded Shizuku

After installing the APK, I selected:

textCopy
Embedded Shizuku

No root and no long-running external Shizuku app were required.

2. Start the private backend through computer ADB

In TensorIMS:

textCopy
Start via computer ADB
→ Generate start command

The app generated a command similar to:

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

The path changes when the app is updated, so use the exact command generated by the app. Keep TensorIMS in the foreground and observe the short startup window shown on screen.

When the backend connects, the UI changes from Disconnected to Ready.

3. Enable only VoLTE

In the China Telecom SIM’s IMS configuration, I enabled VoLTE only:

• VoLTE: on;
• VoWiFi: off;
• VoNR: off;
• VT: off.

Then I tapped Apply changes. The app reported:

textCopy
Applied and verified by reading back

That verification matters. A green switch is only a draft state; the configuration must be read back from the system.

4. Enable persistent VoLTE

A runtime CarrierConfig override should not automatically be treated as permanent. To test reboot behaviour, I opened Advanced tools and enabled:

textCopy
Persistent VoLTE (Experimental)

The page then showed:

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

The feature is explicitly marked Experimental. I used it to avoid needing another USB repair after every reboot while travelling, and I verified it with a real reboot rather than trusting the label alone.

Result

After VoLTE was enabled, Shannon IMS briefly restarted and established an IMS PDN. The key fields changed as follows:

Field	Before	After

TensorIMS also displayed:

textCopy
IMS: Registered
VoLTE: Available

One dumpsys field, Provision-enabled, still read false. In this implementation that did not prevent IMS registration, so it should not be used as the sole success criterion. The meaningful checks are voice service, IMS registration, and an actual carrier-network call.

Reboot verification

A single working runtime state is not enough, because an ephemeral CarrierConfig override may disappear after a reboot. I performed a controlled reboot.

There was one interruption: USB debugging authorization was reset and the device appeared as unauthorized. After confirming the debugging prompt on the phone, I continued.

The important detail is that TensorIMS was not running at that point.

The phone still reported:

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

I started the TensorIMS backend afterward only to query the UI snapshot, which showed:

textCopy
IMS: Registered
VoLTE: Available

That is stronger evidence than “IMS works while the helper app is running”: the persistent VoLTE setting preserved the necessary voice capability across a normal reboot.

LTE-only test

Finally, I repeated the check with Wi-Fi disabled:

1. Disable Wi-Fi;
2. wait for LTE data to stabilise;
3. ping a public address;
4. check the IMS/VoLTE fields;
5. restore Wi-Fi.

The result was 1 packets transmitted, 1 received, 0% packet loss, while VOICE_OVER_LTE, VOLTE_ENABLED_BY_PLATFORM, and LTE_VOICE_CAPABLE remained healthy.

This does not replace a real phone call, but it proves that data was not falling back to Wi-Fi and that the VoLTE configuration did not depend on Wi-Fi.

How to test it yourself

Use a normal phone number, not an emergency number:

1. Place a call and confirm that both sides have audio;
2. ask the other party to call back and confirm ringing and answer;
3. send and receive a normal SMS.

If calls still fail, check two things first:

• whether the voice domain is IN_SERVICE in dumpsys telephony.registry;
• whether TensorIMS reports IMS: Registered.

If IMS is healthy but calls still fail, move on to carrier provisioning, VoLTE entitlement, and real-world coverage. Do not assume that a working APN or baseband is the default suspect.

Rollback and maintenance

• Do not uninstall TensorIMS or clear its app data for the moment.
• If you must uninstall it, run Restore original settings under Advanced tools first.
• Recheck LTE_VOICE_CAPABLE and IMS registration after an OS update or carrier-config update.
• If you switch to another carrier SIM, restore the original settings before starting a new test.
• TensorIMS is a third-party experimental tool. Check the version, device compatibility, and risks before using it.

What I learned

The misleading part of this failure was that the phone had signal and data. From the system’s perspective, however, radio signal, packet data, and IMS voice are three different layers:

• Signal bars describe the radio link.
• Data registration describes the packet-switched bearer.
• VoLTE requires a carrier-config capability, an IMS PDN, and a successful IMS registration.

The useful sequence is: build an evidence chain first, make the smallest configuration change, verify a reboot, and only then discuss persistence and rollback.

No OS reinstall, baseband flash, or APN edit was needed. The missing piece was the right CarrierConfig capability switch, plus enough verification to prove that it actually took effect.