Google Expands Android 17 QPR2 Beta 6 to Pixel 11 Series With New Security Mitigations

Just last week, Google rolled out its Android 17 QPR2 Beta 6 update to eager testers across the globe, but smartphone enthusiasts quickly noticed a glaring omission: the newly launched Pixel 11 series was conspicuously absent from the roster of supported hardware. That temporary gap has now been officially closed. Google has announced and released the Android 17 QPR Beta 6.1 update, extending compatibility to the Pixel 11, Pixel 11 Pro, Pixel 11 Pro XL, and Pixel 11 Pro Fold.

We Knew It Was Coming

Industry watchers and dedicated community members largely anticipated that Google would not leave its newest flagship handsets out of the mix for long, especially given the company’s established commitment to keeping its premier devices at the forefront of the Android beta testing track. The full release notes, now live on the official Google Android Developer portal, outline two distinct build numbers tailored to different segments of the hardware lineup. Build number CP41.260831.011 is designated specifically for the Pixel 11 series, ensuring that the latest generation of hardware receives optimized code designed to match its specialized architecture. Meanwhile, build CP41.260831.007.A3 continues to service all other compatible legacy and contemporary devices participating in the program.

For the most part, the transition onto the beta track for Pixel 11 users is smooth, but there is one specific hardware caveat to look out for in this release. According to the top of the developer release notes, a solitary known issue currently affects the Pixel 11 Pro Fold. The documentation notes that users of Google’s foldable flagship may be required to re-enroll their Face Unlock data after applying the update. While biometric re-enrollment is generally a minor inconvenience rather than a critical system failure, users loading this early software build onto their Pixel 11 Pro Fold should be aware of the requirement before proceeding with the installation.

Beneath that hardware-specific note, Google has also detailed significant security enhancements rolled into the new beta software. The changelog outlines substantial hardening measures implemented to combat increasingly sophisticated call-forwarding fraud schemes. Android 17 QPR2 introduces strict new security restrictions governing programmatic call forwarding, a move designed to shield everyday users from malicious social engineering tactics and unauthorized call redirection.

Under the updated framework, the system now parses and selectively restricts specific call-forwarding USSD codes, such as the common *21# string, when executed programmatically via the TelephonyManager.sendUssdRequest() API. Looking closely at the API restrictions, the sendUssdRequest() method is no longer accessible for call-forwarding codes when applications rely solely on the basic CALL_PHONE permission. Standard third-party applications attempting to execute these sensitive codes autonomously in the background will now be systematically blocked by the operating system and will receive a USSD_ERROR_NOT_ALLOWED callback.

To further combat social engineering scams and unauthorized carrier-level manipulations, Google has implemented a new system-level confirmation dialog. Users who manually dial call-forwarding codes directly within the system dialer will now encounter an explicit, OS-level confirmation prompt before the command is permitted to execute, ensuring that individuals are fully aware of any routing changes being made to their cellular service.

Importantly, non-call forwarding USSD requests remain completely unaffected by these sweeping changes. Everyday functions such as mobile money transfers, balance checks, and standard account inquiries can continue to operate normally without interference from the new security protocols. For developers whose applications are impacted by the tighter restrictions, Google advises verifying that codebases handle the USSD_ERROR_NOT_ALLOWED failure callback gracefully. Applications that require call-forwarding setup workflows and do not qualify for an exempted system role are being encouraged to migrate their implementation to use the ACTION_DIAL intent, which pre-fills the native dialer and leaves the final confirmation securely in the hands of the human user.

As is always the case with pre-release software, early adopters running beta builds may encounter unexpected bugs, performance hiccups, or minor stability issues that can impact daily device usage in various ways. Google routinely encourages members of the beta community to actively report any anomalous behavior, unexpected crashes, or functional problems they experience through the official feedback channels. This collaborative reporting mechanism allows the engineering teams at Google to analyze telemetry data, isolate underlying software bugs, and engineer targeted improvements that can be pushed out in subsequent patch releases or final stable deployments.

It’s All Coming Together

True to its established development cycles, Google continues to distribute beta updates at a swift and steady pace as the software inches closer to a public debut. The final commercial release of Android 17 QPR2 is widely expected to land on supported consumer devices in the coming months. With each successive beta iteration, the software giant works to refine underlying processes, resolve persistent bugs, and implement stability fixes designed to deliver a polished user experience across the entire ecosystem.

While quarterly platform releases are generally welcomed by enthusiasts eager for the latest under-the-hood enhancements and security patches, the practice continues to generate debate within the wider mobile technology community. Some analysts and developers argue that the reliance on quarterly feature drops risks exacerbating software fragmentation across the broader Android landscape. It is entirely possible for two distinct users to operate devices running the exact same core version of Android manufactured by different industry giants like Samsung, Google, and OnePlus, yet experience radically divergent user interfaces, feature sets, and update timelines.

Critics of this approach might argue that Google’s strategy inherently favors its own hardware, effectively granting Pixel devices a distinct operational advantage and an early preview of capabilities that may take months to trickle down to competing hardware ecosystems. Then again, proponents of the model might suggest that this is precisely the intended goal—using vertical integration and software exclusivity to differentiate Pixel hardware in a crowded and highly competitive marketplace.