[Android Software Development] TraderJack:
So I have not seen that specific documentation page before. It is similar to others, but I think it makes the points direct enough that (even if not completely clear) have to be taken at face value.

Based on this documentation I would have to see that the previous description of deviceIntegrity having only two values (MEETS_DEVICE_INTEGRITY and null) with the other's being "labels" is a poor description. It does appear that if you opt in to receive them you can receive them independently as the documentation clearly states again:

It clearly says "ONLY" here, so yeah - I have to take that at face value and amend my previous theories/comments on this.

Therefore it looks like maybe *I* was making it more complicated than it actually is. It would appear that for all intents and purposes the default test is simply:

MEETS_DEVICE_INTEGRITY or FAIL (null)

It appears this is the "standard" that Google thinks most devs will want to meet.

However they are basically giving you two other options one STRONGER and one more BASIC.

Whereas previously I had looked at BASIC/STRONG as subsets of DEVICE, they are really 3 discrete levels which build on each other and infer the lesser levels.

MEETS_BASIC_INTEGRITY

MEETS_DEVICE_INTEGRITY (Default) (Assumes MEETS_BASIC_INTEGRITY)

MEETS_STRONG_INTEGRITY (Assumes MEETS_DEVICE_INTEGRITY, MEETS_BASIC_INTEGRITY)

So if you as a dev decide that MEETS_DEVICE is too strict a level, but you want *some level* of validation you can opt for MEETS_BASIC and if you decide you want something more server you go for MEETS_STRONG.

So putting together the text and the chart we get this:

MEETS_BASIC_INTEGRITY

1) Passes "BASIC system integrity checks" (basicIntegrity/evaluationType=Basic)

MEETS_DEVICE_INTEGRITY

also...

2) Passes "system integrity checks" (basicIntegrity + ???)

3) Android device has Google Play Services (gms - clear enough)

4) Meets android "compatibility requirements" (ctsProfileMatch)

MEETS_STRONG_INTEGRITY

also...

5) Hardware Attestation (basicIntegrity/evaluationType=HARDWARE_BACKED)

A few comments/questions/thoughts about this now.

Based on @1nikolas' testing app, it is clear that many of us were failing MEETS_DEVICE_INTEGRITY prior to setting the ctsProfileMatch of a device which (apparently as far as Google's databases currently show) doesn't require HA.

At the same time we were all passing SafetyNet with: ctsProfileMatched=True/basicIntegrity=True/evaluationType=Basic

So pass SN, fail MEETS_DEVICE_INTEGRITY. And the solution for all was to set a new fingerprint for a profile to match to true (again, presumably a fingerprint which only opportunistically tries to use HA).

It would seemingly be the case then that the ctsProfile database is different for the two APIs. IOW passing ctsProfileMatch for SafetyNet isn't the same as passing ctsProfileMatch for PI-API. Right? If it were truly one-to-one equivalency, then we never would have failed PI-API but passed SN.

Or, are the basicIntegrity checks different for each system dependent on their fingerprint?

I mean all we know at this point from the testing app is our devices (when configured with the new fingerprint from 9/10) can pass with DEVICE_INTEGRITY_MET. Regardless of the other labels that are tested for, we know this means we would pass MEETS_BASIC_INTEGRITY too as that is inclusive. We also know that we would definitely fail MEETS_STRONG_INTEGRITY because we cannot spoof true HA.

It helps to remember the terms from SafetyNet docs:

So in SafetyNet parlance, there were also basically 3 levels:

basicIntegrity (lenient verdict of device integrity)

ctsProfileMatch (a stricter verdict device integrity)

evaluationType=HARDWARE_BACKED (stronger device integrity evaluation)

So its even more clear here that almost nothing has changed.

So there must be some hidden logic here where some PI-API component is saying:

"only require MEETS_STRONG_INTEGRITY if we know the device can definitively do Hardware Attestation (e.g. if it is an 11/12 device)"

"otherwise, if we can't definitively say it does, then MEETS_DEVICE_INTEGRITY is sufficient"

From what I have seen of the configuration of the Play Console I don't know how this could be done.

Also as a side question: isn't SN and the new PI API components of Play Services? If so, how can MEETS_BASIC_INTEGRITY even pass a basic integrity test is Play Services isn't even on the device? What mechanism would they use to report this information if Play Services isn't even installed?