Pixel VoLTE or Wi-Fi Calling Missing? Check Carrier Support Before Using Pixel IMS
A missing toggle, an unprovisioned SIM and failed IMS registration are different problems. Find the layer that failed before changing telephony configuration.

Table of Contents
- Understand the three layers
- First identify the exact symptom
- Ask the carrier a specific question
- What community reports can and cannot tell you
- Try the normal supported setup first
- Pixel IMS is not one single implementation
- A careful way to evaluate the original Shizuku-based project
- Android 16 QPR2 and newer: check persistence separately
- Verify service, not just the switches
- When the switch is on but IMS still will not register
- Use resets and APN changes sparingly
- Build a report a maintainer can use
- Frequently asked questions
- Will Pixel IMS enable VoLTE on every carrier?
- Does it require root?
- Does working 5G data prove voice calling is supported?
- Why did it stop working after a reboot?
- Should I switch ROMs just for Wi-Fi calling?
- The goal is reliable calling
- Sources and scope
Your Pixel has fast mobile data, but calls drop to another network. Or your carrier advertises Wi-Fi calling and the option is missing from the phone.
Searching for a fix quickly leads to Pixel IMS. The screenshots look convincing: enable a few switches, apply the settings and the missing features appear.
Pixel IMS can change how a supported Pixel exposes or requests IMS features. It cannot guarantee that your carrier provisions those services, accepts your exact device, or successfully registers the phone on its network. A switch being enabled and a working voice service are different results.source 4source 3
Start by identifying which result is missing. Do not modify your only working phone connection without another reliable way to communicate.
Understand the three layers
You do not need to become a mobile-network engineer, but separating these layers prevents a lot of wasted effort.
| Layer | The practical question | Evidence to look for |
|---|---|---|
| Device configuration | Does the phone consider this feature available for this SIM? | Settings, effective carrier configuration and supported device software |
| Carrier provisioning | Has the carrier enabled the service for this line, plan and device? | Confirmation from the carrier or its activation process |
| Runtime IMS service | Has the phone registered and can it complete the intended call? | Relevant registration/voice status plus an ordinary real-world call test |
AOSP describes IMS as a connection between Android and the vendor or carrier's implementation. It is not merely a normal application switch.source 2
Android also includes carrier-entitlement mechanisms that can query a carrier's service status and handle activation requirements. Some carriers require a service portal or emergency-address information for Wi-Fi calling.source 3
That is why enabling a local preference cannot substitute for every part of activation.
First identify the exact symptom
“VoLTE not working” can describe several different experiences:
- The feature is absent from Settings.
- The setting is present but cannot be enabled.
- The setting stays enabled, but the service does not register.
- Calls work on mobile coverage but not over Wi-Fi.
- Everything works until the next reboot or Android update.
Choose the closest description and record the phone's model, Android build, carrier, SIM/eSIM and whether it uses stock software or a named ROM.
For a dual-SIM phone, identify the actual line used for the test. Do not assume a status readout for one SIM describes the other.
Ask the carrier a specific question
Instead of asking “do you support Wi-Fi calling?”, ask:
Your provider may support a feature generally without supporting every imported handset or plan. Google's Pixel help explicitly tells users to verify carrier support and fees for Wi-Fi calling.source 1
Do not publish your full IMEI, subscriber identifiers or account information in a forum while trying to establish compatibility. Supply sensitive identifiers only through the carrier's official secure support channel when required.
What community reports can and cannot tell you
An r/InternetPH discussion about VoLTE and VoWiFi activation contains people comparing carrier requests, enabled settings and different Wi-Fi networks.source 8 It illustrates the questions readers actually have, but it does not prove present-day support for every carrier in that thread.
There is an additional trap: discussion participants mention both Pixels and other phones running Pixel-like software. Those are not the same hardware test.
A report becomes useful when it includes the model, build, carrier, plan, date and actual successful call behavior. “Works on Pixel” is not enough.
Try the normal supported setup first
Install available official system updates and check the relevant SIM settings. On Pixel, Google's help places Wi-Fi calling under Settings > Network & internet > SIMs, subject to the available carrier controls.source 1
Complete any carrier activation or terms shown by the legitimate system or carrier app. Do not enter account credentials into an unrelated “VoLTE unlock” website.
Then test on a trusted Wi-Fi network and on normal mobile coverage. Wi-Fi calling can route differently depending on preference and signal strength, so being connected to Wi-Fi does not alone prove the call used it.source 1
If practical, compare the same SIM in another supported phone, or another known-working SIM in the Pixel. Keep the comparisons separate and avoid deleting an eSIM just to create a test.
Pixel IMS is not one single implementation
Two public projects surfaced during this research. Their names overlap, but their setup and maintenance expectations are different.
| Project | Documented approach | Important limitation |
|---|---|---|
kyujin-cho/pixel-volte-patch, branded Pixel IMS | Uses Shizuku's ADB-backed access to override relevant carrier configuration on selected Tensor Pixels | Maintainer warns that changes may need reapplication after reboot on Android 16 QPR2 Beta 3 and newer |
TakaiSaisei/pixel_ims | Uses the phone's own wireless-debugging endpoint, with per-SIM Apply/Restore and an optional boot reapplication feature | Repository capabilities are not proof of a tested stable release or universal carrier compatibility |
The original project lists its directly testable carrier separately from community-reported carriers.source 4 The second project's README describes loopback ADB, live status and carrier dependence. Its Releases section did not expose a published release in the research snapshot, so this guide does not invent a recommended APK download or declare it a stable successor.source 5
Do not follow a tutorial for one implementation while installing an APK from the other. Our wireless ADB guide explains pairing, connection ports and authorization, but the chosen Pixel IMS app still needs its own documented setup.
A careful way to evaluate the original Shizuku-based project
Use the original maintainer's supported installation source and current requirements. Treat this as an optional configuration experiment after normal carrier checks, not a prerequisite for every Pixel.
A controlled evaluation is:
- Record the working state and confirm another means of communication is available.
- Install and start Shizuku using its official setup instructions.
- Confirm Shizuku actually says it is running, then authorize the legitimate Pixel IMS app.
- Select the relevant SIM where the app offers that choice and record existing settings.
- Change only the feature you are investigating, using the controls in that installed version.
- Check the resulting status and make an ordinary test call.
- Restore defaults if service becomes less reliable or the change provides no useful result.
The original project's instructions document its Shizuku requirement and VoLTE control; Shizuku's own guide explains the different startup methods.source 4source 7
Do not enable every advanced telephony option at once. A result is much easier to interpret when there is only one deliberate change.
Android 16 QPR2 and newer: check persistence separately
The original maintainer warns that configuration changes may not persist after reboot beginning with Android 16 QPR2 Beta 3 and newer.source 4
This makes old “reboot twice and forget it” advice unreliable for current builds. Check your state after the reboot and after an OS update. Do not assume an apparently successful configuration remains applied indefinitely.
Likewise, the alternative project's optional “apply on boot” feature is a maintainer-described capability, not proof that it will work under every current Android build and background restriction.source 5
Record whether a failure is the configuration disappearing or registration failing despite the configuration remaining enabled. Those are different reports.
Verify service, not just the switches
A useful post-change test checks the intended SIM, service availability and actual call behavior.
An IMS registration indicator is valuable, but interpret it in context. Registration can involve different services or transports; do not reduce the entire diagnosis to one green label. AOSP distinguishes registration information from the voice, video and messaging features exposed through IMS.source 2
For VoLTE, test an ordinary incoming and outgoing call in suitable mobile coverage with Wi-Fi disabled. Observe the relevant service information where your build exposes it. Do not use a status-bar icon as the only evidence.
For Wi-Fi calling, check the phone's Wi-Fi-calling indication and the carrier's recommended test procedure. If you temporarily use airplane mode with Wi-Fi re-enabled as part of a supported test, remember that you are changing connectivity and restore normal settings afterwards.
Never place practice calls to emergency numbers. Successful ordinary calls also do not independently certify emergency-calling behavior or every roaming situation. Keep a reliable alternative while investigating.
When the switch is on but IMS still will not register
Do not keep adding overrides simply because the first one failed. Return to the layer table.
Confirm that the line is provisioned, the exact device/software combination is supported and there is no carrier outage. For Wi-Fi-only failures, compare trusted networks. If one network works and another does not, a fresh ROM installation is not the first explanation to pursue.
For a custom ROM or generic system image, the telephony implementation itself needs attention. In an XDA Pixel 6a GSI discussion, a user reported working service on stock software but missing IMS-related calling on a GSI; a configuration patch did not solve it.source 9
That was an individual report, not proof of a universal GSI defect. It demonstrates why a config utility cannot be assumed to supply missing or incompatible ROM components.
Use resets and APN changes sparingly
The original project's troubleshooting page includes more invasive options, including network resets and carrier-specific configuration work. It also warns not to erase active eSIMs when resetting mobile-network settings.source 6
Do not copy another carrier's IMS APN into your phone because its name looks plausible. Use the APN and provisioning instructions your carrier provides for your exact service.
Likewise, removing carrier system packages is not a universal fix. It can change behavior beyond the one feature you are testing. A historical guide for a particular imported handset should not become a bulk-uninstall script for every Pixel.
Start with the app's supported reset-to-defaults or Restore action for the affected SIM. Record whether ordinary calling returns before making a different change.
Build a report a maintainer can use
A useful report separates configuration from the result:
Phone model and Android build:
Stock OS or exact ROM/version:
Pixel IMS repository, app version and source:
Shizuku or loopback-ADB implementation:
Carrier, country and plan type:
Physical SIM or eSIM; affected SIM slot:
Carrier confirms this model/line is provisioned: yes/no/unknown
Feature missing, disabled or enabled-but-not-working:
Relevant IMS registration and voice availability:
Ordinary incoming/outgoing call results:
Wi-Fi network comparison:
What changes after reboot or system update:
Whether restoring defaults changes the result:
Redact identifiers and account information. Do not post live wireless-debugging pairing codes or full unreviewed telephony logs.
Frequently asked questions
Will Pixel IMS enable VoLTE on every carrier?
No. Configuration changes cannot guarantee carrier acceptance, provisioning or a compatible runtime IMS implementation.source 3source 2
Does it require root?
The original documented route uses Shizuku and ADB-backed privileges without rooting the phone. The alternative repository describes a different local-ADB approach.source 4source 5 Neither should be confused with an ordinary app that has no elevated capabilities.
Does working 5G data prove voice calling is supported?
No. Data connectivity and the relevant voice service are different things to verify. Check the intended SIM and actual call behavior.
Why did it stop working after a reboot?
Check whether the override is still applied. The original project explicitly documents persistence limitations on newer Android builds.source 4 Do not assume the carrier suddenly changed its policy.
Should I switch ROMs just for Wi-Fi calling?
Not before confirming carrier support and the ROM's exact device-specific telephony status. A different ROM can change the problem rather than solve it.
The goal is reliable calling
A useful fix is not a screenshot with every option enabled. It is a configuration that works on your actual line, survives the conditions you care about and can be restored if something goes wrong.
Check carrier provisioning first, use one clearly identified tool only when appropriate, and distinguish configuration, registration and completed calls. That is a much better path than searching for a universal “VoLTE unlock” switch that does not exist.
Sources and scope
Research checked September 28, 2026. Maintainer feature claims are attributed, historical community reports are contextual, and no carrier/device pair was physically tested for this article. No universal compatibility or emergency-calling guarantee is made.
- Source 1: Google Pixel Help, mobile connectivity and carrier-dependent Wi-Fi calling. Open source
- Source 2: AOSP, “Implement IMS,” platform/vendor interface, registration and service features. Open source
- Source 3: AOSP, IMS service entitlement, provisioning and carrier activation requirements. Open source
- Source 4: Original Pixel IMS maintainer README, supported approach, directly tested versus community carriers, and reboot-persistence notice. Open source
- Source 5: TakaiSaisei/pixel_ims, maintainer README and repository release state. Open source
- Source 6: Original Pixel IMS troubleshooting guide, including the eSIM reset warning. Some proposed changes are carrier-specific and are not generalized here. Open source
- Source 7: Shizuku official startup instructions. Open source
- Source 8: r/InternetPH, historical discussion of carrier activation, device settings and different Wi-Fi networks. Not a current carrier-support matrix. Open source
- Source 9: XDA, Pixel 6a GSI/DSU IMS discussion, December 2023. Individual report comparing stock and GSI behavior. Open source

