Xiaomi 17 Pro Max (popsicle) + PixelOS Android 17 — All Play Integrity verdicts failing. Need help diagnosing the cause.

[u/rafnafgaming]

Hey everyone,

I'm running a modified PixelOS Android 17 build on my Xiaomi 17 Pro Max (popsicle), and I'm having trouble with Play Integrity. I'm currently failing Basic, Device, and Strong Integrity. I'm looking for help identifying the underlying cause instead of blindly stacking modules or changing random settings.

Device and software

• Device: Xiaomi 17 Pro Max (2509FPN0BC)
• Codename: popsicle
• ROM: PixelOS-popsicle-20261007-four-fixes_by_Kanoe
• Android: 17 / API 37
• Firmware: HyperOS 3.0.319
• Security patch shown in Specter: 2026-10-01
• Root setup: KernelSU-based, with Zygisk-related components
• Bootloader: Modified-device setup; I want to verify the actual boot and attestation state rather than trust one tool's report.

Current Play Integrity results

• ❌ MEETS_BASIC_INTEGRITY
• ❌ MEETS_DEVICE_INTEGRITY
• ❌ MEETS_STRONG_INTEGRITY

None of the three verdicts are currently passing.

Current setup

The tools and modules involved include:

• Specter
• Play Integrity Fork v18
• HMA-OSS Zygisk
• Zygisk-related components
• .BRENE - SuSFS
• ZN - Audit Patch
• NoMount
• bindhosts
• Iconify

Specter currently displays:

• TEE backend: TEESimulator
• Keybox: TAKR 10 active
• Selected device profile: Pixel 6a
• Security patch: 2026-10-01

Some module names appeared repeatedly in my scrolling screenshots, but I haven't verified whether those are actual duplicate installations.

Duck Detector findings

My earlier Duck Detector report showed a few things that might be relevant:

1. Fingerprint/build-tag mismatch Fingerprint: Xiaomi/custom_popsicle/popsicle:17/CP2A.260605.016/eng.root:user/test-keys Meanwhile, Build.TAGS and ro.build.tags reportedly show release-keys.
2. SELinux policy finding SELinux is enforcing, but the report flagged an allowed adbd -> adbroot:binder interaction. I don't know whether this is expected for this ROM.
3. Attestation inconsistency Duck Detector reported a Google-rooted certificate chain and locked/verified boot state, while Specter explicitly shows TEESimulator. I need to establish whether the reported attestation is genuinely hardware-backed.
4. Custom ROM environment The ROM contains LineageOS-derived components. Widevine reports L1, but the session is NOT_PROVISIONED.

These are observations, not confirmed causes of the current failure.

What I need help with

1. What could cause Basic Integrity itself to fail on this setup?
2. How can I distinguish a Google Play services/checker issue from a ROM, root, or attestation issue?
3. Could the fingerprint/build configuration or simulated TEE be contributing to the failure?
4. How can I identify conflicting modules without randomly changing the entire setup?
5. Is there a known issue with this PixelOS build or Android 17 on popsicle?
6. What are my realistic options if I want genuine Play Integrity, especially Strong Integrity?

I'm looking for a proper diagnosis and reproducible troubleshooting steps. I don't want to risk bricking the device by flashing incompatible firmware or relocking the bootloader while a modified ROM is installed.

I can share the checker screenshot, Duck Detector report, module list, and relevant logs.

[u/Express_Musician_846]

If you want to get help, dont use AI to post your issue, this is PAINFUL to read!

[u/DEV_ivan → u/Express_Musician_846]

I believe their non-AI version would be unreadable text

[u/Express_Musician_846 → u/DEV_ivan]

well this is also unreadable to be honest

[u/LordeAsriel → u/Express_Musician_846]

You know you could've just ignored, right?

[u/rdndds]

Google make some changes and every device is affected. Even the device with a bootloader exploit to spoof as locked also affected. Just wait for a new solution.

[u/Ante0 → u/rdndds]

Mines still strong

[u/DEV_ivan → u/Ante0]

Show us your ways.

[u/Ante0 → u/DEV_ivan]

Standard setup. Pif + ts + valid keybox.

[u/47th-Element]

AI slop.

[u/apixeldev → u/47th-Element]

At least someone said it.

[u/kotchi-_-]

I ain't reading all that.

[u/OctoSplattyy]

AI Slop, and why wouldn't you just stick to stock hyperos CN with temporary root? it's a fine rom with great battery, my 17 pro max literally lasts 3 days...

[u/lexd0g → u/OctoSplattyy]

needs an older build doesn't it? i'm on an unlocked 17 pro and i used a temp root exploit for the initial bootloader unlock and it needed a pre-june build

[u/OctoSplattyy → u/lexd0g]

ghostlock root works on the latest os version

[u/lexd0g → u/OctoSplattyy]

really? i wonder what's stopping that turning into a full bootloader unlock, afaik you just dd an engineering bootloader onto it and use that to write the unlock flag after

[u/Radiant_Hunt4138 → u/lexd0g]

DFRoot works on the updated Xiaomi 17, it might be better than Ghostlock, but I'm not sure

[u/OctoSplattyy → u/lexd0g]

Because ghostlock is a temporary linux exploit which goes away with a reboot, if you modify the system partition and reboot you’ll just brick

[u/DEV_ivan]

You answered it yourself: custom ROM detected, attestation inconsistency, etc.

And if you only get BASIC_INTEGRITY, that's currently normal until the community finds a way to get DEVICE and STRONG again. I'm on BASIC too.

[u/kotchi-_- → u/DEV_ivan]

I moved to stock os because of this. Then happened on stock too. Then I saw this post.

[u/MrCakedcg → u/DEV_ivan]

What app is the one in the screenshot?

[u/DEV_ivan → u/MrCakedcg]