Telegram

HELP GOOGLE FI ACTIVATION HANGS INDEFINITELY TRICKY STORE + PIXEL 10 PRO SPOOF

Help] Google Fi Activation Hangs Indefinitely (Tricky Store + Pixel 10 Pro Spoof)

We understand the frustration of dealing with a stubborn activation loop, especially when utilizing advanced rooting techniques like Tricky Store to spoof a cutting-edge device like the Pixel 10 Pro. The scenario you described—where the Google Fi app authenticates the account successfully but hangs indefinitely on the “Downloading SIM…” phase—is a complex issue that sits at the intersection of carrier security, Google Play Integrity API enforcement, and custom ROM/modification environments.

We have analyzed the configuration, the troubleshooting steps taken, and the specific “Pixel 10 Pro Blazer” context within the 2026 timeframe. This guide provides a deep-dive technical analysis and a comprehensive roadmap to resolve the activation hang. We will dissect the potential failure points, ranging from the Zygisk detection vectors to the nuances of Remote Key Provisioning (RKP) enforcement on Android 16.

Understanding the Google Fi Activation Architecture

To fix the issue, we must first understand what the Google Fi application is doing during the “Downloading SIM…” phase. This is not merely a file download; it is a secure cryptographic handshake between the device, Google’s servers, and the carrier’s network core.

The Role of Play Integrity and Device Attestation

When you initiate an eSIM download, the Google Fi app queries the Play Integrity API. This API provides a verdict on the device’s integrity state. In your specific case, the device is rooted, the bootloader is unlocked, and you are spoofing a future device (Pixel 10 Pro). The Play Integrity verdict likely returns a “MEETS_DEVICE_INTEGRITY” failure or, at best, a “MEETS_BASIC_INTEGRITY” that is insufficient for carrier-level operations.

Tricky Store is used to inject a valid keybox to bypass this. However, simply having a keybox is not enough. The keybox must match the device fingerprint you are spoofing, and the underlying system properties must not trigger internal logic bombs within the Fi app.

Why It Hangs Instead of Failing

The indefinite hang suggests a timeout or a loop in the application logic. The app likely receives a response from the server that it cannot parse due to a mismatch in the expected device capabilities or a failed cryptographic signature on the request payload. If the app expects a specific hardware identifier (e.g., a Titan M3 chip identifier for the Pixel 10 Pro) and the spoofed software environment returns a generic or mismatched value, the handshake deadlocks.

Analyzing Your Configuration and Troubleshooting Steps

We have reviewed your chronological attempts to fix the issue. While many were correct, some may have inadvertently complicated the situation.

The “Zombie Firewall” Fix and Network Integrity

You correctly identified and removed the afwallstart script. This is critical. Google Fi is extremely sensitive to network manipulation. Any VPN, ad-blocker, or firewall rule that intercepts traffic on ports 443 or 5228 can cause the eSIM download to fail. Since Chrome loads fine, we can confirm basic connectivity, but we must ensure that the Google Fi app has a completely unobstructed path to *.google.com and *.android.com endpoints.

Tricky Store Targets: The “Big 4”

Selecting com.google.android.apps.tycho (Fi), gms (Play Services), ims (Carrier Services), and vending (Play Store) is the correct strategy. However, the order of operations matters. If the keybox injected into gms does not align with the props injected into tycho, attestation fails. We must verify that the keybox used is fresh and specifically targets the blazer hardware name.

The teeBroken=true Conundrum

This is likely the primary culprit. You noted that teeBroken=true is reported. This indicates that the Trusted Execution Environment (TEE) is considered compromised (usually due to an unlocked bootloader). While you attempted to override this with remote_provisioning.tee.rkp_only=0, we must consider how Android 16 handles this.

On Android 16 (BD3A), Google has tightened Remote Key Provisioning (RKP). If teeBroken=true, the device cannot perform hardware-backed attestation. Even with a spoofed keybox, the server may detect that the keybox was not provisioned through a secure TEE. The rkp_only=0 flag attempts to allow software-based provisioning, but Google Fi may reject requests originating from devices where the hardware root of trust is broken.

Step-by-Step Resolution Strategy

We recommend a systematic approach to isolate the variable causing the hang. Follow these steps precisely.

Step 1: Cleaning the Environment

Before adjusting props, we must ensure the environment is pristine.

  1. Disable Magisk/KernelSU: Temporarily remove root access to test if the Fi app blocks rooted devices entirely during the initial provisioning. If it works unrooted, we know the issue is strictly attestation.
  2. Clear All Data:
    pm clear com.google.android.apps.tycho
pm clear com.google.android.gms
pm clear com.android.vending
pm clear com.google.android.ims
  3. Delete Boot Hashes: Navigate to /data/adb/tricky_store/ and delete any boot_hash files. This forces Tricky Store to recalculate the hash based on your current boot image.

Step 2: Refining the PIF (Pixel Interface) Configuration

Your custom.pif.prop is well-structured, but for a Pixel 10 Pro spoof to work with a 2026 keybox, we need to adjust the fingerprint and security patch to match the latest available keybox generation. Keyboxes are date-bound.

Recommended custom.pif.prop Adjustments: Ensure the SECURITY_PATCH matches the keybox generation date. If you are using a keybox from January 2026, the patch must be late 2025 or early 2026.

MANUFACTURER=Google
MODEL=Pixel 10 Pro Fingerprint
FINGERPRINT=google/blazer/blazer:16/BD3A.251105.010.E1/14337626:user/release-keys
BRAND=google
PRODUCT=blazer
DEVICE=blazer
RELEASE=16
ID=BD3A.251105.010.E1
INCREMENTAL=14337626
TYPE=user
TAGS=release-keys
SECURITY_PATCH=2025-11-05

Crucial Addition for Android 16: Android 16 introduces new properties. We need to spoof the DEVICE_INITIAL_SDK_INT to ensure the app thinks it is running on a native Android 16 environment, not a compatibility layer.

Add to your PIF:

DEVICE_INITIAL_SDK_INT=36

Step 3: Handling teeBroken and RKP

You mentioned setting remote_provisioning.tee.rkp_only=0. This is a good start, but on Android 16, the system property might be read-only at boot. You must use a boot script to enforce this before Google Play Services starts.

Create a boot script in /data/adb/service.d/:

#!/system/bin/sh
# Wait for system to settle
sleep 15
# Force RKP to allow software fallback
resetprop remote_provisioning.tee.rkp_only 0
# Also set teeBroken to 0 to mask the bootloader status visually
resetprop teeBroken 0

Note: While resetprop is powerful, Google Fi checks the attestation result, not just the boolean teeBroken property. If the keybox is not signed by Google for the specific hardware ID (blazer), the attestation server will reject it regardless of this property.

Step 4: The Tricky Store Keybox Strategy

For the Pixel 10 Pro (Blazer), you need a keybox that is valid for that specific device name.

  1. Target Selection: In Tricky Store, ensure spoofBuild=1 and spoofProps=1 are active. This ensures that when the attestation request is generated, it uses your custom.pif.prop values.
  2. Keybox Injection: Ensure the keybox is injected into gms and tycho. If you are using a universal keybox, it may not work. You need a keybox specifically provisioned for a device with the blazer hardware name.
  3. Spoofing Vendor: If you are using PIF or Play Integrity Fix, ensure spoofProvider=1 is set. This tells the module to hook the ProviderInstaller class, which is often used by Fi for secure network connectivity.

Step 5: The “Airplane Mode” and Wi-Fi Activation

You attempted this, but we need to refine the method.

  1. Disconnect Mobile Data: Ensure no SIM is active.
  2. Enable Airplane Mode.
  3. Re-enable Wi-Fi.
  4. Open Google Fi: The app should detect Wi-Fi and attempt activation over the internet (eSIM download) rather than over the cellular network.
  5. If it still hangs: The issue is strictly the network packet handshake. Wi-Fi activation bypasses the radio checks but intensifies the software attestation checks.

Step 6: Alternative Identity - Downgrading to Pixel 9 Pro

You tried downgrading to Pixel 9 Pro (Caiman). This is often a valid workaround, but it introduces a new problem: Keybox Mismatch.

If your keybox is for a Pixel 10 Pro (Blazer) but you are spoofing a Pixel 9 Pro (Caiman), the hardware ID in the keybox certificate will not match the spoofed device. This causes an immediate failure. You must obtain a keybox that matches the fingerprint you are spoofing.

Recommendation: If you have a keybox for Caiman (Pixel 9 Pro), use a PIF configuration for Caiman. If you have a keybox for Blazer (Pixel 10 Pro), stick to the Blazer configuration.

Advanced Debugging: What to Look For

To diagnose the exact failure point, we need to look at the logs.

Logcat Analysis

Connect your device to a computer and run ADB Logcat. Filter for Fi and Gms.

adb logcat | grep -E "Fi|Tycho|Gms|Integrity"

What to look for:

  1. PlayIntegrity: Request failed: This indicates the attestation is failing. Check the error code. ERROR_PLAY_INTEGRITY_NO_ERROR is good. Anything else (like ERROR_PLAY_INTEGRITY_MANIFEST_MISMATCH) indicates a bad keybox or mismatched fingerprint.
  2. Tycho: Download failed: This is the Fi app specific error. It often points to a network timeout or a server rejection of the eSIM request payload.
  3. ProviderInstaller: installIfNeeded: If this fails, the secure connection to Google’s servers cannot be established. This is usually a signature mismatch.

Simulating the 2026 Context

Since the date is January 2026, ensure your system clock is accurate. However, if you are using a keybox generated in the future (which is impossible), you must use a keybox from the present or past. If the keybox certificate has expired, the attestation will fail, and the Fi app will hang waiting for a valid response.

Date Spoofing: Do not spoof the system date to the future. Keep the system date on automatic (NTP). Spoofing the date can invalidate the keybox signature validation.

Final Checklist for Resolution

Before retrying the activation, verify the following:

  1. Root State: Hide root via Magisk DenyList (or Zygisk Next) for com.google.android.apps.tycho, com.google.android.gms, and com.android.vending. Even with a valid keybox, some carrier apps refuse to run if they detect root binaries.
  2. PIF Config: Verify spoofSignature=0 and spoofVendingFinger=0 in your advanced settings. We want to mimic the device, not the Play Store signature, to avoid detection conflicts.
  3. Tricky Store State: Ensure boot_hash is not stale. If you patched your boot image recently, delete the hash file.
  4. Permissions: Double-check that com.google.android.apps.tycho has Location (Always), Phone, and SMS permissions. The Fi app needs Location to determine the nearest cell tower for eSIM provisioning.
  5. Network: Disable any Private DNS (DoT) or DNS over HTTPS. Use the default ISP DNS or Google DNS (8.8.8.8).

Conclusion

The indefinite hang on “Downloading SIM…” is a defensive mechanism triggered by Google’s servers detecting an inconsistency in the device’s cryptographic identity. Given the “Pixel 10 Pro” spoof on a rooted device, the most probable cause is a failed Play Integrity attestation due to the teeBroken status or a mismatch between the spoofed hardware and the injected keybox.

By aligning the PIF fingerprint exactly with the keybox generation, enforcing the remote_provisioning.tee.rkp_only=0 flag via boot script, and ensuring the Tricky Store targets are correctly configured for the 2026 Android 16 environment, the activation should proceed. If the issue persists, the keybox itself may be invalid for the specific blazer hardware ID, necessitating a new keybox sourced specifically for the Pixel 10 Pro lineage.

Follow the refined steps above, monitor the logs, and isolate the attestation failure to resolve the activation loop.

You also may like 〣〣
Explore More
Redirecting in 20 seconds...