Add additional PixelPropsUtils props to workaround

[bphd]

No description provided.

[osm0sis]

Seems unnecessary, .pi is the one that matters.

[bphd]

Seems unnecessary, .pi is the one that matters.

Can tell you that on my CROM if I don't touch these very properties, my CROM continues to push its own dead fingerprint. It's absolutely necessary. Installing PIFF don't do anything about that because it's not the right properties

[osm0sis]

Oh weird, I was just going on what @joeyhuab told me from EvoX. Maybe things have further deviated from there? Thoughts @joeyhuab? 🤔

[osm0sis]

@bphd Is the .gapps one for certain necessary in your setup? Seems like .pi and .gms would cover it where we only ever spoof to GMS.

[bphd]

@bphd Is the .gapps one for certain necessary in your setup? Seems like .pi and .gms would cover it where we only ever spoof to GMS.

Idk really. Tested with both as it was already a big journey enough to debug my way out. Cross testing that would have been even heavier

You have two choice, either apply both of them and wait for user complain to have lost functionalities to revert (but I lost none on my part). Either apply one of them and user will still think that PIFF don't patch their case and wouldn't know how to help themselves (because it's honestly not obvious to find such properties, so maybe applying them both would take a thorn out of one's foot that they don't even think they would have been able to do themselves)

Personally I suggest the former, it's really not that big of a risk for a sure reward

[osm0sis]

You can't just quickly test it without the .gapps entry on your setup?

[bphd]

You can't just quickly test it without the .gapps entry on your setup?

It's not quick, so can't be done "quickly", and no I can't test, I switched CROM

I suggest you the former to actually help people getting device integrity and avoid them weeks-month of helplessness

[osm0sis]

@bphd What ROM was the behavior you were seeing on, by the way? I'd like to recreate it and check some things in the logs. 👍

[bphd]

@bphd What ROM was the behavior you were seeing on, by the way? I'd like to recreate it and check some things in the logs. 👍

Old version of Matrixx. But it still is in operation on many CROM latest version. You can figure out where it still is operative simply by searching such properties on GitHub. Repositories where it still hasn't changes still is in effect. But as of today, new variable are used but the problem remains the same for CROM that still try to inject FP/KB by themselves or tweak properties where not needed. Or worse, refuse any Google attestation and call it a day, that less to support ig

[osm0sis]

@bphd Thanks, what version of Matrixx though? My point was some versions of PPU will work with what I had in the first place and some will only work after what you've added, so I want to make sure I'm using the exact one you had.

[osm0sis]

I tried official Matrixx builds for hotdogb from here: https://sourceforge.net/projects/projectmatrixx/files/Android-14/hotdogb/

Went through v10.5.3, v10.6.2, v10.7.3, v10.8.1, v10.9.0, v10.9.1 and v10.10.0 and I don't see any of the persist.sys.pixelprops.* props in question from our commits there. 🤔

[bphd]

by searching such properties on GitHub

[osm0sis]

Sure, but it's pretty frustrating playing 20 questions with you and then having to do my own research when you've had the answer this whole time..

[osm0sis]

I'm also surprised this commit worked for you at all since after searching GitHub as you suggested I don't see a single instance of both persist.sys.pixelprops.pi and persist.sys.pixelprops.gapps/persist.sys.pixelprops.gms being in the same version of PPU... 🤔

Anyway, found an old version of crDroid for one of my devices that should have gms/gapps props per their commit history, so I'll get it working. 😉

https://github.com/crdroidandroid/android_frameworks_base/blob/14.0-20240706/core/java/com/android/internal/util/crdroid/PixelPropsUtils.java#L38