![\"Incoming](\"https:\/\/www.newsbeep.com\/uk\/wp-content\/uploads\/2025\/08\/google-phone-app-incoming-call-screen-pixel-10-pro-scaled.jpg\"\/ "\\"google")
<\/p>\n<\/p>\n
Joe Maring \/ Android Authority<\/p>\n
TL;DR<\/p>\n
Google broke the Pixel IMS app that enabled VoLTE\/VoWiFi on unsupported carriers, but the developer has already released a new workaround.
\nGoogle\u2019s October update patched a loophole that the app exploited, specifically blocking the \u201cshell\u201d user from calling a restricted internal API.
\nThe new fix bypasses this restriction by \u201claundering\u201d the API call through another component, so the system doesn\u2019t detect it coming from shell.<\/p>\n
Back in early 2023, a Korean developer released an app called \u201cPixel IMS\u201d that lets Pixel users enable VoLTE and VoWiFi on any carrier. This app is useful for people who import Pixel phones<\/a> into certain countries, as Pixels lack VoLTE and VoWiFi support in many of the markets where they aren\u2019t 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<\/a>. Users who depended on the app to enable these crucial calling features were disheartened by Google\u2019s action, but fortunately for them, a new workaround has already been found.<\/p>\n Don\u2019t want to miss the best from Android Authority?<\/p>\n Last week, Google released the October 2025 update<\/a> for Pixel phones to address a variety of display and UI issues. Although this month\u2019s security bulletin didn\u2019t 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 \u201coverrideConfig cannot be invoked by shell.\u201d<\/p>\n overrideConfig is an internal API in Android\u2019s telephony framework that allows callers to override the carrier configuration<\/a> \u2014 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<\/a>.<\/p>\n 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<\/a>, an open-source tool that allows other apps to run as the \u201cshell\u201d user. The shell user has elevated privileges necessary for testing and debugging apps through the Android Debug Bridge (ADB)<\/a>. Because platform developers at Google also use ADB to test new configurations, the shell app was granted the MODIFY_PHONE_STATE permission.<\/p>\n 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\u2019t deemed a high enough risk under the new Risk-Based Update System (RBUS)<\/a> to be included in this month\u2019s security bulletin, but Google rolled out the fix nonetheless.<\/p>\n Google\u2019s 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.<\/p>\n Over the weekend, the developer implemented a solution<\/a> that bypasses Android\u2019s new restriction. Instead of making a direct call to the overrideConfig API, Pixel IMS now uses<\/a> 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, \u201cclean\u201d user.<\/p>\n Of course, this new method isn\u2019t 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.<\/p>\n 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!<\/p>\n![\"google](\"https:\/\/www.newsbeep.com\/uk\/wp-content\/uploads\/2025\/10\/google_preferred_source_badge_light@2x.png\"\/ "\\"google"){kind=icon}
![\"google](\"https:\/\/www.newsbeep.com\/uk\/wp-content\/uploads\/2025\/10\/google_preferred_source_badge_dark@2x.png\"\/ "\\"google"){kind=icon}
<\/a>How Google tried to stop Pixel users from enabling VoLTE everywhere, and why it failed<\/p>\n![\"Pixel](\"https:\/\/www.newsbeep.com\/uk\/wp-content\/uploads\/2025\/10\/Pixel-IMS-app-enable-VoLTE-scaled.png\"\/ "\\"Pixel")
![\"Pixel](\"https:\/\/www.newsbeep.com\/uk\/wp-content\/uploads\/2025\/10\/Pixel-IMS-enabling-VoLTE-on-unsupported-Korean-carrier.jpg\"\/ "\\"Pixel")
<\/p>\n