Google tried to kill this Pixel VoLTE-enabling app, but the developer already has a fix

Back in early 2023, a Korean developer released an app called “Pixel IMS” that lets Pixel users enable VoLTE and VoWiFi on any carrier. This app is useful for people who import Pixel phones into certain countries, as Pixels lack VoLTE and VoWiFi support in many of the markets where they aren’t directly sold by Google. However, Google pushed an update last week that patched the loophole the Pixel IMS app used to forcefully enable VoLTE and VoWiFi, breaking the app in the process. Users who depended on the app to enable these crucial calling features were disheartened by Google’s action, but fortunately for them, a new workaround has already been found.

How Google tried to stop Pixel users from enabling VoLTE everywhere, and why it failed

Last week, Google released the October 2025 update for Pixel phones to address a variety of display and UI issues. Although this month’s security bulletin didn’t mention any vulnerabilities, Google quietly included a patch that closed the specific loophole used by the Pixel IMS app to enable VoLTE and VoWiFi. This patch caused the app to crash whenever users tried to toggle VoLTE or VoWiFi, with a crash log stating that “overrideConfig cannot be invoked by shell.”

overrideConfig is an internal API in Android’s telephony framework that allows callers to override the carrier configuration — a set of carrier-specific keys the OS reads to determine which connectivity features to enable. Normally, carriers provide these keys directly, but the overrideConfig API can override them. Since third-party apps are not meant to have this level of control, the overrideConfig API is not public.

Instead, overrideConfig can only be called by apps holding the MODIFY_PHONE_STATE permission, which is restricted to privileged system apps. So how did Pixel IMS use this API? It leveraged Shizuku, an open-source tool that allows other apps to run as the “shell” user. The shell user has elevated privileges necessary for testing and debugging apps through the Android Debug Bridge (ADB). Because platform developers at Google also use ADB to test new configurations, the shell app was granted the MODIFY_PHONE_STATE permission.

The Pixel IMS app exploited this to use the overrideConfig API, a loophole that Google left untouched for over two and a half years. Recently, however, Google classified this loophole as a high-severity privilege escalation vulnerability. Despite this classification, it wasn’t deemed a high enough risk under the new Risk-Based Update System (RBUS) to be included in this month’s security bulletin, but Google rolled out the fix nonetheless.

Google’s fix added a check to the overrideConfig API, blocking access if the calling process was the shell user. This broke the Pixel IMS app, as it relied on running as the shell user to call the API.

Over the weekend, the developer implemented a solution that bypasses Android’s new restriction. Instead of making a direct call to the overrideConfig API, Pixel IMS now uses an indirect method, launching an Instrumentation component to make the API call on its behalf. This circumvents the restriction because the call no longer appears to come from the shell user; in essence, the app is laundering its API call through a different, “clean” user.

Of course, this new method isn’t foolproof. Google could patch it in several ways, with the most effective being the complete removal of the MODIFY_PHONE_STATE permission from the shell app. This would be an effective killswitch, as the new loophole only works because the shell app still technically has the necessary permission to call the overrideConfig API.

The question is, how aggressively will Google go after Pixel IMS and similar apps? Would a complete block of Pixel IMS stop you from importing a Pixel phone? Let us know why or why not in the comments below!