[INFO] Play Integrity API - replacement for SafetyNet

Search This thread

chiteroman

Senior Member
Nov 4, 2019
527
575
22
Oviedo
Samsung Galaxy J7
Xiaomi Mi A2 Lite

V0latyle

Forum Moderator
Staff member
@pndwal and others, any knowledge of the "under the hood" link between Play Integrity responses and Play Protect certification?

Did some experimenting on my Pixel 5, stock rooted TQ2A.230505, with USNF MOD 1.2:
  • Disabled UNSF module, rebooted, confirmed Play Integrity reports fail of both BASIC and DEVICE labels. Play Store still reports "Device is certified", even though Play Integrity check in store dev options shows no labels
  • Cleared Play Store cache. Still reports "Device is certified"
  • Cleared all Play Store data. Certification simply disappears, it does not explicitly say "Device is uncertified"
  • Enabled USNF module, rebooted. Confirmed pass of both BASIC and DEVICE labels. Play Store does not report certified.
  • Cleared Play Store data. Now reports "Device is certified"
 

rodken

Senior Member
Jan 11, 2010
1,861
853
@pndwal and others, any knowledge of the "under the hood" link between Play Integrity responses and Play Protect certification?

Did some experimenting on my Pixel 5, stock rooted TQ2A.230505, with USNF MOD 1.2:
  • Disabled UNSF module, rebooted, confirmed Play Integrity reports fail of both BASIC and DEVICE labels. Play Store still reports "Device is certified", even though Play Integrity check in store dev options shows no labels
  • Cleared Play Store cache. Still reports "Device is certified"
  • Cleared all Play Store data. Certification simply disappears, it does not explicitly say "Device is uncertified"
  • Enabled USNF module, rebooted. Confirmed pass of both BASIC and DEVICE labels. Play Store does not report certified.
  • Cleared Play Store data. Now reports "Device is certified"
Ironic.
-- I went through the same experimental regime a few months ago on my OnePlus 8 and was able to hit pay dirt.
 

zgfg

Senior Member
Oct 10, 2016
9,577
7,437
Redmi K20 / Xiaomi Mi 9T
Xiaomi Mi 11
@pndwal and others, any knowledge of the "under the hood" link between Play Integrity responses and Play Protect certification?

Did some experimenting on my Pixel 5, stock rooted TQ2A.230505, with USNF MOD 1.2:
  • Disabled UNSF module, rebooted, confirmed Play Integrity reports fail of both BASIC and DEVICE labels. Play Store still reports "Device is certified", even though Play Integrity check in store dev options shows no labels
  • Cleared Play Store cache. Still reports "Device is certified"
  • Cleared all Play Store data. Certification simply disappears, it does not explicitly say "Device is uncertified"
  • Enabled USNF module, rebooted. Confirmed pass of both BASIC and DEVICE labels. Play Store does not report certified.
  • Cleared Play Store data. Now reports "Device is certified"
Device is certified takes some time

Long ago (before PI) it's been discussed about. IDK how it works now

Eg, once (like two years ago), after deleting Data for PlayStore app, I needed couple of hours to get it showing Device is certified - until then, it was neither Certified nor Not certified, but SN was passing with no problem
 

V0latyle

Forum Moderator
Staff member
Ironic.
-- I went through the same experimental regime a few months ago on my OnePlus 8 and was able to hit pay dirt.
What do you mean?
Device is certified takes some time

Long ago (before PI) it's been discussed about. IDK how it works now

Eg, once (like two years ago), after deleting Data for PlayStore app, I needed couple of hours to get it showing Device is certified - until then, it was neither Certified nor Not certified, but SN was passing with no problem
In this case it was immediate. Clearing data then relaunching Play Store updates the certification status. Interesting that it doesn't seem to explicitly indicate whether a device is not certified, only if it is
 
  • Like
Reactions: Homeboy76

Lughnasadh

Senior Member
Mar 23, 2015
5,486
6,544
Google Nexus 5
Huawei Nexus 6P
It once took close to a day for it to show up as either certified or not certified for me after clearing Play Store data. That was a while ago. Once it does show up , it has always indicated either "Device is certified" or "Device is not certified".
 
  • Like
Reactions: ipdev

V0latyle

Forum Moderator
Staff member
It once took close to a day for it to show up as either certified or not certified for me after clearing Play Store data. That was a while ago. Once it does show up , it has always indicated either "Device is certified" or "Device is not certified".
Interesting, did you have dev options enabled in Play Store?

I only got "Device is certified", I never got the "not certified" message

Also, were you clearing all Play Store data or just cache?
 

Lughnasadh

Senior Member
Mar 23, 2015
5,486
6,544
Google Nexus 5
Huawei Nexus 6P
Interesting, did you have dev options enabled in Play Store?

I only got "Device is certified", I never got the "not certified" message

Also, were you clearing all Play Store data or just cache?
Currently, I do have dev options enabled in Play Store and it shows "Device is not certified". It has also shown this without dev options enabled. Cleared both Play Store data and cache. I don't ever remember it being different than this.
 

V0latyle

Forum Moderator
Staff member
Currently, I do have dev options enabled in Play Store and it shows "Device is not certified". It has also shown this without dev options enabled. Cleared both Play Store data and cache. I don't ever remember it being different than this.
Interesting. I should have taken screenshots.

I assume you're failing DEVICE_INTEGRITY?
 

pndwal

Senior Member
@pndwal and others, any knowledge of the "under the hood" link between Play Integrity responses and Play Protect certification?

Did some experimenting on my Pixel 5, stock rooted TQ2A.230505, with USNF MOD 1.2:
  • Disabled UNSF module, rebooted, confirmed Play Integrity reports fail of both BASIC and DEVICE labels. Play Store still reports "Device is certified", even though Play Integrity check in store dev options shows no labels
Seems Play Protect only checks periodically.
  • Cleared Play Store cache. Still reports "Device is certified"
Not enough to force Play Store refresh.
  • Cleared all Play Store data. Certification simply disappears, it does not explicitly say "Device is uncertified"
Forced Play Store refresh but any cached Play Protect measurements are too old... Play Store is waiting for a periodical Play Protect attestation check.

You should get an instant result by clearing Play Services data where Play Protect is still included, or by additionally clearing Google Play Protect Service app in late systems. (I still don't have this w/ A11 stock MIUI.)
  • Enabled USNF module, rebooted. Confirmed pass of both BASIC and DEVICE labels. Play Store does not report certified.
Reboot most likely refreshes Play Protect cached measurements (triggers new attestation check), or USNF may may cause this with a Play Services refresh.
  • Cleared Play Store data. Now reports "Device is certified"
Forced Play Store refresh and cached Play Protect measurements are fresh enough to be accepted.
---------​

Play Store does take some time to catch up with gms attestation without intervention like G Pay/Wallet does (up to a week?), but clearing data seems to make it poll Play Protect service immediately... The Play Protect service was embedded in Google Play Services till recently but in late systems it's seperated out to new Google Play Protect Service app.

For me results have generally been instant, but I've also generally cleared Play Services data at the same time to refresh it's cached measurements (incl. Play Protect service); Play Store apparently waits for Play Protect to periodically refresh attestation results if its cached results are too old. Nb. if on a late system with seperate Google Play Protect Service app you'll also need to clear its data to get refreshed results.

For a long while after June 2022 (PI rollout) Play Protect service was still polling S/N ctsProfileMatch only... That's why many wondered why bank apps failed despite Play Protect returning 'Device is Certified' or wouldn't show in Store. (S/N ctsProfileMatch was passing with older USNF but many devices needed the later added fingerprint prop based mismatch in addition to bypass new fingerprint prop based hardware-backed verdict enforcement and pass PI deviceIntegrity... Devices launched with A13+ also need shipping level prop mismatch.) I'd say Google may have simply been waiting for some critical mass of bank apps to move Play Protect device certification result to PI deviceIntegrity. I'm not sure, but Play Integrity may have migrated also by now. Nb. Playstore correctly excludes apps based on several different criteria so displayed Play Protect device certification result is only one of several device compliance measurements that are actually known by Play Store.

🤠 PW
 
Last edited:
  • Like
Reactions: ipdev and V0latyle

chiteroman

Senior Member
Nov 4, 2019
527
575
22
Oviedo
Samsung Galaxy J7
Xiaomi Mi A2 Lite
@pndwal and others, any knowledge of the "under the hood" link between Play Integrity responses and Play Protect certification?

Did some experimenting on my Pixel 5, stock rooted TQ2A.230505, with USNF MOD 1.2:
  • Disabled UNSF module, rebooted, confirmed Play Integrity reports fail of both BASIC and DEVICE labels. Play Store still reports "Device is certified", even though Play Integrity check in store dev options shows no labels
  • Cleared Play Store cache. Still reports "Device is certified"
  • Cleared all Play Store data. Certification simply disappears, it does not explicitly say "Device is uncertified"
  • Enabled USNF module, rebooted. Confirmed pass of both BASIC and DEVICE labels. Play Store does not report certified.
  • Cleared Play Store data. Now reports "Device is certified"
Device is certified = passing MEETS_DEVICE_INTEGRITY (and MEETS_BASIC_INTEGRITY).

To reset it, clear GSF and GMS data.
 
  • Like
Reactions: V0latyle

IlyasPro

Member
Feb 14, 2022
11
5
Redmi 9
do you guys know how to pass cts profile match please in couple months my device was and still unable to use banking apps because google play certification is not certified
Screenshot_2023-05-30-15-36-06-729_gr.nikolasspyr.integritycheck.png
 
Last edited:

pndwal

Senior Member

V0latyle

Forum Moderator
Staff member
  • Like
Reactions: ipdev and pndwal

IlyasPro

Member
Feb 14, 2022
11
5
Redmi 9
I don't know how to thanks you you are a life saver so there is a module cause this entire issue, It looks like strong integrity is still failing but it doesnt matter finally I got to login to my account again thanks you so much
Screenshot_2023-06-01-12-10-28-073_gr.nikolasspyr.integritycheck.png
 
Last edited:
  • Like
Reactions: ipdev and pndwal

pndwal

Senior Member
I don't know how to thanks you you are a live saver so there is a module cause this entire issue, It looks like strong integrity is still failing but it doesnt matter finally I got to login to my account again thanks you so much
View attachment 5923595View attachment 5923599
Please say which mod... May help others... I suspect it may be have been MHPC configuration(?)

Nb. There's no need to alter fingerprint prop globally w/ MHPC if using current USNF builds as that's now an integrated function...

FYI, you won't ever pass strongIntegrity unless your device has defective implementation of components relaying chain of trust data from hardware keys...

Happily for us, no banks are known to use PI strongIntegrity (equivalent to old S/N API returning ctsProfileMatch pass w/ evaluationType: HARDWARE_BACKED, BASIC) yet...

👍 PW
 
  • Like
Reactions: IlyasPro

Top Liked Posts

  • There are no posts matching your filters.
  • 4
    In case it's helpful, some banking apps rely on local bootloader attestations instead of Play Integrity, as it was in my case. The lsposed module "BootloaderSpoofer" fixed this problem. Took me half a year to figure this out.
    3
    How do I test Integrity if I have a "older" Play service version?
    Google Play Services, its GMS process is just a man-in-the-middle or 'messenger'

    It downloads the.apk (so called droidGuard), you will find (not just the latest but also the whole bunch of their older versions) at:
    /data/data/com.google.android.gms/app_dg_cache
    Open each subfolder there, it will contain one version of the apk

    And that the.apk (droidGuard) performs SaferyNet/PlayIntegrity attestation

    Attached is a hacker's pdf study that was already discussed and circulated here on XDA in this or similar theeads

    That's how it works since 2019 or so (already at the time of SafetyNet, prior to Play Integrity), hence if your Google Play Services supports attestation, it should already work that way

    This makes possible for Google that they don't depend on the new/old GMS. Instead they can always (without user's consent) update:
    - the.apk (droidGuard)
    - bytecode that droidGuard always calls from Google server (and that bytecode actually collects data for attestation)
    - SafetyNet/PlayIntegrity verdict logic that Google server sends at the end (telling you what you pass or not)

    That's the way how they eg two months ago closed their flaw with Strong Integrity - they didn't need at all to update ours Google Play Services - and they didn't

    They oftenly, once or twice a week update the.apk (droidGuard) and nobody could know how often and when they update the verdict logic on their server and even the bytecode that the.apk pulls on every attestation
    2
    In case it's helpful, some banking apps rely on local bootloader attestations instead of Play Integrity, as it was in my case. The lsposed module "BootloaderSpoofer" fixed this problem. Took me half a year to figure this out.
    Glad you got to the bottom of that... Baffles me why they bother to do local validation and stop short of Googles model gift-horse... It must have a nice mouth... 🤪
    2
    I believe the Play Integrity fix is supposed to do this as well.
    Nah... Key Attestation (Verifying hardware-backed key pairs) is an independent approach... PW
    2
    Probably a misunderstanding then. Reading your statement I felt like you are somewhat asking developers to implement strong, while being a rooted user, very weird?
    Nope, was asking the rhetorical question of "why aren't they using PI" but as you pointed out, if they did, that would affect a significant portion of their user base
    After all, we have already known that the big banking bois and Google has won the modding game with PI strong.
    Eh...dunno if it's so much a game as it is mousetraps and idiots. Someone always builds a better mousetrap, then eventually someone makes a better idiot
  • 37
    Play Integrity API

    What is Play Integrity?

    Play Integrity is an API that is used by applications to determine device compatibility and security state. It has replaced SafetyNet for the most part, with a deadline of January 2025, when Google's SafetyNet servers will go offline. Apps that continue to exclusively depend on SafetyNet will no longer work once this happens. Most developers have already migrated to Play Integrity.

    How is Play Integrity different from SafetyNet?
    In many ways, it's very similar. It uses many of the same checks as SafetyNet, but the responses have been made a bit simpler.

    Is Play Integrity the same as Play Protect?
    No. Play Integrity provides users with the ability to verify device compatibility and security, much like SafetyNet did. Play Protect is a part of the Play Store that ensures that your device is certified, and helps to protect against malware. The Play Protect certification result does depend on your DEVICE_INTEGRITY result, but it is possible to pass Play Protect while failing Play Integrity, and vice versa, see here.

    Why does this matter?
    Like SafetyNet, apps use this API to determine a device's compatibility and security state. Failing verdicts may limit your ability to use those apps.

    My device passes SafetyNet but I can't use Google Pay/other apps.
    Don't rely on SafetyNet as a good assessment of your device's compatibility and security. It is possible to pass SafetyNet, but fail Play Integrity. Make sure you are specifically checking your device's Play Integrity verdicts.
    Rooted Pixel 5 on stock firmware: USNF 2.3.1 shows SafetyNet Pass using YASNAC, but device fails Play Integrity DEVICE_INTEGRITY check.

    How do I know if my device is passing Play Integrity checks?
    To check Play Integrity status, you can do so through the Play Store.
    Tap the Profile icon in the upper right, go to Settings > About > Tap Play Store version 8 times. This unlocks developer mode in the Play Store.
    Now go to Settings > General > Developer options > Check integrity.
    If you prefer a clear visual indicator, you can use this app:​
    This app not only checks Play Integrity verdicts, but checks for traces of root, Magisk, and Xposed:
    If you're a nerd and you want to see key attestation details, use this:
    What can I do to fix it?
    It depends on your device and software state.
    Fixing this requires artificial measures - either you'll have to use a Magisk module, or the fixes in the module must be baked into the ROM you're using.
    • If you are on the OEM ROM, or a custom ROM that hasn't been "fixed", you can use the USNF Displax Mod to pass BASIC and DEVICE verdicts. This "tricks" Play Integrity into thinking that the device is not capable of hardware backed attestation, which will force a fallback to basic attestation. You MUST be rooted with Magisk to use this module. Unrooting will still fail.
    • If you are on a custom ROM that has Play Integrity fixes baked in, you should already be passing. Please refer to that ROM's thread for support.
    You shouldn't need to use MagiskHide Props Config with this module, even if you're on a custom ROM.
    Note: There is no solution that can be flashed in recovery.
    For support with this Magisk module, see this thread.
    Why doesn't the original Universal SafetyNet Fix work?
    This project is not consistently maintained and does not include the necessary fixes. Please use @Displax's fork.​
    Do I need to pass STRONG integrity?
    This is ultimately up to the individual app developer. We don't know which ones may require this result, we only know which ones don't. Google, coincidentally, is not one of these - to use GPay/Wallet, you only need BASIC and DEVICE.
    Please note that the only attestation requriements Google can enforce is for thier own apps. They cannot require any third party app to use hardware backed attestation. That's the whole point of providing the Play Integrity API - it's simply a means for developers to determine how secure your device is.
    It's also worth noting that many if not most "security intensive" apps out there rely on third party security engines that often look for additional signs a device might be modified; see the next point below.
    If you are having problems with a specific app, chances are that app uses its own root detection methods; you may need to use additional modules such as Shamiko. You can post in this thread for help.​
    I'm passing BASIC and DEVICE but an app is still detecting root. What do I do?
    Some apps may implement their own root detection methods. Oddly enough, it seems that Google has documented a means for app developers to verify crytographic hardware keys without using Play Integrity at all,​
    Other methods of root detection may include:​
    • checking for the presence of a SU binary
    • checking for the presence of a root manager app such as Magisk or SuperSu
    • checking for traces of Zygisk / Xposed / LSPosed
    • checking for permissive SELinux
    • chekcing whether USB Debugging is enabled
    It's a game of cat and mouse with these, as the methods they use are not always clear. Please be aware that this thread is ONLY intended for support with passing Play Integrity, and questions regarding hiding root for individual apps should be referred to the this thread.
    What causes a device to fail Play Integrity checks?
    It depends on your Android version and device state:

    • Locked bootloader with stock firmware running Android 7.1.2 or older will only pass BASIC and DEVICE. STRONG will never pass.
    • Locked bootloader with stock firmware running Android 8.0 or newer should pass all 3
    • Unlocked bootloader with unrooted stock firmware will fail all 3. STRONG will never pass.
    • Unlocked bootloader with Magisk rooted stock firmware will fail all 3 unless specific Magisk modules are used. STRONG will never pass.
    • Unlocked bootloader with custom firmware will fail all 3 (unless fixes are baked in). STRONG will never pass.
    Versions of Android prior to 8.0 will only pass BASIC_INTEGRITY and DEVICE_INTEGRITY even if unmodified. Hardware backed attestation was introduced in Android 8.0; previous versions are not capable.
    What do the verdicts mean?
    The three elements in Play Integrity are:​

    • MEETS_DEVICE_INTEGRITY: Corresponds to SafetyNet ctsProfileMatch. The app is running on an Android device powered by Google Play services. The device passes system integrity checks and meets Android compatibility requirements. (Device profile matches that of a device that has passed Compatibility Test Suite) A device that fails this will appear as Uncertified in Play Store.
    • MEETS_BASIC_INTEGRITY: Corresponds to SafetyNet basicIntegrity. The app is running on a device that passes basic system integrity checks. The device may not meet Android compatibility requirements and may not be approved to run Google Play services. For example, the device may be running an unrecognized version of Android, may have an unlocked bootloader, or may not have been certified by the manufacturer. Most devices should pass this, even if they're rooted.
    • MEETS_STRONG_INTEGRITY: Corresponds to SafetyNet HARDWARE_BACKED evaluationType. The app is running on an Android device powered by Google Play services and has a strong guarantee of system integrity such as a hardware-backed proof of boot integrity. The device passes system integrity checks and meets Android compatibility requirements. An unlocked bootloader will ALWAYS fail this label because boot integrity cannot be verified, meaning that hardware backed attestation methods cannot be used.
    This table shows the relationship between SafetyNet and Play Integrity responses:​
    1665499433643.png
    The most fundamental change is this: Play Integrity, by default, uses hardware methods to verify BASIC and DEVICE integrity, but also uses the same hardware methods as proof of boot and system integrity. What this means is that Play Integrity uses stronger (and unbreakable!) methods as "proof" of the BASIC and DEVICE verdicts, and uses the availability of these hardware backed methods to determine the STRONG_INTEGRITY verdict.
    These hardware methods include hardware-backed key attestation as well as Verified Boot to verify that a device has not been tampered with. It is not possible to pass STRONG integrity on an unlocked and/or modified device, or a pre Android 8 device. (Notable exception being devices with broken keystores such as ASUS ROG) << Google recently revoked ASUS ROG keys, this device won't pass STRONG even on a locked bootloader
    Fortunately, we have the ability to force a basic attestation method that prevents the use of hardware checks, meaning it is possible to partially pass. Universal SafetyNet Fix MOD by @Displax does this:
    (Response from Play Integrity Checker on my rooted Pixel 5 with Universal SafetyNet Fix MOD by Displax)
    1667488774837.png
    As far as how this is going to affect us in the future, it's up to the app developers to decide what results they want. In most cases, all they care about is BASIC and DEVICE. But if they really want to ensure that they're running on a trusted platform, they can require STRONG attestation, which cannot be spoofed or bypassed. BASIC and DEVICE can, because they use the same mechanisms that SafetyNet did. The million dollar question is whether they ever will.
    It is worth noting that SafetyNet always provided the means for developers to force hardware backed evaluation types; none did, including Google. The same seems to still be true; most app developers require DEVICE verdict, "secure" apps require BASIC and DEVICE, but none are known to require STRONG.
    For those interested in the timeline:
    1684775003484.png
    For the majority of us, this does not matter, unless you're using an old app that has not migrated to Play Integrity. For app developers, this means that new apps must use Play Integrity.​
    For more information, please read the discussion in this thread.​
    10
    Some Insight on the New Cat and Mouse Game...

    Since many are asking:
    Is there a fix for this? ... Can't pass MEETS_STRONG_INTEGRITY.
    I'm posting this WOT. 🤪

    I predict some will like it, some won't... You've been warned! 😜

    FWIW, Play Integrity MEETS_STRONG_INTEGRITY is akin to SafetyNet Evaluation type HARDWARE with CTS Profile match...

    Banks could have used this before (w/ S/N API) but haven't as it would have excluded too many users/devices/customers... Nothing has actually changed with new PI API; MEETS_STRONG_INTEGRITY will exclude the same group, so it's doubtful they'll rush to require this verdict...

    Basically, the means to enforce Hardware key-backed Attestation has already been here w/ either of these attestations, but banks don't want to exclude all those w/Android 7 and below, or many w/ broken keymaster 3+ implementations in Android 8+ devices (CTS Profile match with HARDWARE Evaluation type / MEETS_STRONG_INTEGRITY won't pass with locked bootloader), eg most OnePlus devices (nb. Keymaster may have been fixed in OnePlus devices launched with Android 12+)...

    I'm guessing the banks may well leverage this at some point if the time arrives when they feel there is a sufficient critical mass of devices w/ working hardware-backed keymaster (ie w/ hardware keystore, A8+) to trade against the number of modded (bootloader unlocked) devices in use especially if they deem Google slow to close the fallback-to-basic-attestation loophole that has allowed modders to bypass hardware based attestation to CTS Profile match enforcement (by triggering fallback to BASIC Evaluation type as well as bypassing enforcement) and also to allow its counterpart, MEETS_DEVICE_INTEGRITY verdict. (Nb. This verdict should not properly be obtained on modded devices, and it requires the same attestations as S/N as well as the same tricks to trigger fallback to BASIC attestation and bypass enforcement) The incentive to use this foolproof means is also certainly being weighed constantly against the cost / need to use their own custom means of sophisticated 'root' detection...

    Google also, as other authorities have commented, appears to be waiting for some 'acceptable' percentile / critical mass of such devices in use to be reached also, before they swing the 'big hammer' that is Hardware-backed Key Attestation enforcement and that will definitely spell the endgame for modders' use of bank apps, and possibly for OnePlus users and others whose devices have broken keymaster*

    *Nb. There are exceptions, eg Asus ROG Phone 3, where broken keymaster actually results in PI MEETS_STRONG_INTEGRITY and S/N CTS Profile match with Evaluation type HARDWARE regardless of bootloader status instead of the converse...

    It seems likely to me that OnePlus and other devices with broken keymaster can be spared if Google do prevent on-device triggering of fallbacks to basic attestation use simply by using device info contained in the cryptographic attestation sent to Google servers instead of userspace model props etc now used, to bypass enforcement at the server end. If they do this it would be a concession as modded OnePlus etc may then still be able to pass CTS Profile match / DEVICE_INTEGRITY while other modern modded devices won't...

    This would, however, be a way to swing the hammer a bit sooner, and either way, as can be seen from the above, they may be forced to do this once banks do indicate a willingness to enforce
    MEETS_STRONG_INTEGRITY in order to stop a landslide that would prevent all stock locked Android 7 and lower devices using bank apps etc... Or maybe they'll just let the landslide go and force bank app users to upgrade devices...

    Hopefully this gives some insight regarding what pressures may finally force Google to properly deploy (ie. strictly enforce) Hardware-based Key Attestation on devices that support it...

    Personally, I think Google has exercised great restraint, possibly out of some regard for the modding community since I can't see any other compelling reason not to have properly enforced CTS Profile match with HARDWARE Evaluation type where supported or Hardware attested MEETS_DEVICE_INTEGRITY sooner, unless the matter of ensuring that the API properly sees hardware identifiers (ie. these cannot be spoofed, which I believe would again require cryptographic server-side attestation that the device doesn't indicate the presence of hardware keystore) for bypassing hardware attestation enforcement in devices launched with Android 7 and earlier is proving difficult (but I'm fairly sure this mechanism will be a simple matter for Google and probably already in place)... 😛

    It may well be that Google is benevolently holding off but is using/will use MEETS_STRONG_INTEGRITY uptake data as tha natural indicator of the banks propensity for reliable HKA... My bet is that if Google doesn't have immediate plans to move to srtict HKA enforcement for MEETS_DEVICE_INTEGRITY, then they will when the banks themselves move to use the even stricter MEETS_STRONG_INTEGRITY verdict...


    👀 🤠
    7

    MOD ANNOUNCEMENT

    All posts discussed here regarding Telegram links, the rules & policy of XDA concerning them, has been moved to THIS THREAD
    At the very least, this is not the thread to discuss it as this thread is about "[INFO] Play Integrity API - replacement for SafetyNet" and even if OP is okay with off-topic discussion, discussing it in a dedicated thread in "About xda.developers.com" section or even the "Feedback/Recommendations for XDA" thread would be a more appropriate and conducive location for such a discussion than here. Please direct/continue further discussions to the above URL.
    6
    FYI: Migration deadline (for app developers) and full turndown deadlines for SafetyNet Attestation API have been extended.

    Migration Deadline: End of January 2024
    Full Turndown: End of January 2025

    6
    @Displax may say more later...
    For STRONG integrity you just need:
    1. Buggy "walleye" product, device, model and fingerprint "google/walleye/walleye:8.1.0/OPM1.171019.011/4448085:user/release-keys".
    2. Set derivative "DEVICE_INITIAL_SDK_INT" to "O" (26) for GMS.
    3. Set global prop "ro.product.first_api_level" to >= 33 / or `null`. Or delete it at all.

    Check this commit: https://github.com/Displax/safetynet-fix/commit/79f6ef22db5eeb717c57a9bd00ee90b8d7cd2201