[Android Software Development] TraderJack:
To be clear, the new "Play Integrity API" is a new check that is failing now on many systems.

I guess part of the issue is to figure out exactly why/how and determine if there is a fix. I don't think there is one that will last.

Previously we usually worried about two different checks to make sure all of our apps would download and function properly.

The first was "Play Protect certification" which is visible in the About section of the Play Store settings. I think there have been several methods that were used to determine certification here, but it isn't dependent just on the Play Store app, but more so the Play Services Framework.

It used to be that hiding these services using MagiskHide was sufficient, until Google enhanced and enforced the SafetyNet API, specifically the Hardware Attestation. That was the big rigmarole ~1-2 years ago and what Universal SafetyNet Fix (USNF) has allowed us to get by for the recent past. USNF basically spoofs a keystore which forces SafetyNet to fallback to using Basic instead of Hardware key Attestation (https://github.com/kdrag0n/safetynet-fix/blob/master/docs/details.md).

As mentioned there, we also still needed to pass Basic Attestation with CTS Profile/fingerprint which is where MagiskHide Props Config (MHPC) comes in to set a profile for a phone that will at least pass Basic Attestation.

Using all these things in conjunction (MagiskHide, USND, MHPC) is what has kept us in business for the past year or two.

Now the problems have come two-fold:

First, Magisk has changed and removed MagiskHide. The Deny list that comes with the new versions will disable Magisk from applying anything to those apps listed, but it doesn't hide the presence of Magisk to an app. The LSposed devs have created Shamiko which is a module which can hide Magisk, Zygisk and related modules. I'm not exactly sure how it works, I think it is probably similar to how the old MagiskHide did (don't quote me). But once you enable it as a Magisk Module it uses Magisk's "Configure Deny List" settings to enforce hide (NB: when using Shamiko you want to ensure that the "Configure Deny List" in Magisk settings is setup, but that you don't "Enforce DenyList" as Shamiko does its work instead).

Second, and the big issue at hand:

The introduction, and now partial enforcement of the new(er) Play Integrity API.

In the past, we could ensure that we were passing certification and SafetyNet checks by looking at the Play Store (device certified status), and running any one of the various SN checker apps available. However even passing those checks now is not enough to guarantee things will work anymore because of the new PI-API.

Others have linked above to some articles which explain the basics of how it works. @1nikolas has made the awesomely simple Play Integrity API Checker (which I'm sure there will be more of), which does a simple check to see if the device is passing the check. If you read the articles about how PI-API works and as @1nikolas cautions in another post, this app doesn't verify all the aspects that can be checked with this API. According to the doc overview 3 things can be verified:

Genuine app binary

Genuine Play install

Genuine Android device

I'm pretty sure the first two require the App checking to actually be uploaded to the Play Store, and I believe he is working on an updated app that can do that. App developers will be able to check all these things, but most likely the one giving us the biggest issue now (and the one @1nikolas does check for) is that it is a Genuine Android device.

The question is (which I'm sure others can answer), how is this API checking for and determining if we are on a genuine (or unmodified) device and why are we failing this check when SafetyNet is doing the same thing and we have been able to fool it?

I *think* the answer has to do with Hardware Attestation. Somehow the new PI-API is looking at the device fingerprint and saying "Hey you have a Google Pixel 3 XL running Android 12. You should support Hardware Attestation, so let's use it".

At this point, either the PI-API is finding another way to check for HA that USNF can't get around, or more likely (I *think*) it is failing HA and saying "Well, you should support Hardware Attestation, but the best I can do is Basic. And that isn't good enough...so something must be wrong...and therefore FAIL".

IOW, Basic Attestation was good enough for SafetyNet, but not for the new PI-API.

My further assumption is that the current workaround, which is to use MHPC to set an older device is simply matching devices and profiles to a list that Google is maintaining as to which devices should support the new API fully. Google is pretty confident that a Pixel 3 XL running 12 should support HA and the new API, but maybe they are concerned about breaking older devices so a 3XL running 9 is still set as a "soft pass" as it were in their databases.

This is my guess (also based on some other conversations in the forum here) as to why we are currently able to still work around the enforcement of the new PI-API by setting our devices to an older OS version (and/or possibly an entirely different model depending on our device).

Personally I tried all of the original workarounds but was still failing according to @1nikolas API Checker and GPay was telling me I couldn't add a card because my device was modified. Even so, Play Certification was OK and SafetyNet passed no problem.

I first tried to change my fingerprint with MHPC to "One Plus 5 - Android 9", but even after clears and reboots that didn't work. I then changed it to "Pixel 3XL - Android 9" and I was able to pass. Ofc I should probably have tried my phone model first, but someone with a One Plus 5 responded that fingerprint worked for them. I find it interesting (because I'm not sure why), the other fingerprint didn't work on my phone when it did function successfully on another (after all one whole point of MHPC is to emulate another device through its props).

Hopefully with the ground set with the above, those more knowledgeable can chime in to offer corrections, clarifications, and theories on where we can go now....