[Magisk] pndwal:
This was not meant to be a criticism, and I don't think you began using the term 'banned'... I think the Dev here did?...

However I think we need to be accurate, especially as your excellent guide has been 'stickied' in other threads and may be a go-to guide here...

I haven't caught up with all posts here, but I can see (also in private conversations) that many are really getting confused by the notion that Google is apparently 'banning' prints, and the obvious question about whether stock/locked devices using such 'banned' prints now fail DEVICE_INTEGRITY, suddenly fail to support bank apps etc using PI DEVICE_INTEGRITY etc, has already been asked several times...

Unless some with stock/locked devices can demonstrate that the prints now actually break CTS/VTS, I think we should steer away from all misleading terms (or those with potential to contribute to confusion) including "banned"... "Introduced new measures to prevent prints being used in other devices" would be more accurate....

If the stock/locked devices that Google purposely exempts from HARDWARE_BACKED evaluationType (including late OnePlus etc) have DEVICE_INTEGRITY in the wild, we should certainly be able to spoof using at least current print/associated prop combinations those devices use simply because they are not using any strongly attested measurements, meaning that the signals are all effectively coming from 'userspace', and we can spoof anything there!...

My point is that we shouldn't be resigned to those prop combinations being "banned"... We should be figuring out what extra property cross-checks Google is doing, adding such props in pif.json file (or adjusting the combinations/values to pass) and continuing to use these prints which MUST still be usable without triggering PI HARDWARE_BACKED evaluationType enforcement. As I said:

... I don't think we can conclude that the Nexus devices are 'banned' from tests where BASIC_INTEGRITY is failing either for reasons detailed... You/we need to understand what is breaking that before connecting it with DEVICE_INTEGRITY which will necessarily fail where BASIC_INTEGRITY is lacking...

The other points are just technical details, but will hopefully be helpful to those trying to understand this thing properly and the additional cross-checking that Google seems to be doing already as well as may potentially add...

😕... There should be room for it...

Some of that post may be 'nuance', but essentially what I wrote goes to cracking new Google methods (that are clearly crackable) rather than just accepting (erroneously) that Google has "banned" these prop combinations, and just looking for combinations that simply work with what we've got from a pot rapidly getting smaller and smaller... I want to see that happen so we can continue to use any print/prop combos that don't trigger HARDWARE_BACKED evaluationType enforcement in the wild (ie. in stock/locked devices)...

And such 'nuance' is needed to head off the (somewhat justified) confusion that exists already in my book... And to properly answer a number of members who've already spotted the conflicting information and asked about it. 😉 ... Hope the above helps convince you to correct technical errors in a Go-to guide at least...

Again, please take what you will from this; it's not a criticism. - Hoped it might be a contribution... But the game of cat and mouse we play is a highly technical one, and technical players are winning ATM!

Love your work; Excellent guide, great script utility... So good to have active contributors like you, @chiteroman, @badabing2003 etc.

🙂 PW