[Discussion] Google Pay Magisk Discussion Thread

Search This thread

pndwal

Senior Member
Unfortunately Revolut Bank app says that it won't work on rooted phones when Enforce Denylist option is disabled.
🤔 How does it say that?
I must confess that I'm still using Magisk 25.2 with application name changed. Because some dumb apps find rooted phone based on an installed app called "Magisk".
That's not dumb... It's par for the course...

Have you ever installed / tested Shamiko hiding?

Nb. Currently I'm running an unofficial test fork which showcases new NB Zygisk loading, but Revolut is no different to other apps... It runs fine with proper root hiding and with DenyList disabled... I'll add it to my post here:
https://forum.xda-developers.com/t/discussion-magisk-the-age-of-zygisk.4393877/post-88468151

Also, is Magisk 26.1 fundamentally better than version 25.2?
Each iteration has fixes / enhancements but can also have regressions (especially if considering Canary builds)... Please see release note to know what they are...

FWIW, Native Bridge Zygisk implementation will be a big one...

😜 PW
 

wtosta

Senior Member
Apr 26, 2015
52
24
Pszów
HTC 10
Samsung Galaxy S9
How does it say that?

It says... Revolut is not supported on rooted devices.
screenshot_20230427_161312_revolut_proc-jpg.5898451
 

Attachments

  • Screenshot_20230427_161312_Revolut_proc.jpg
    Screenshot_20230427_161312_Revolut_proc.jpg
    37.2 KB · Views: 59
Last edited:

wtosta

Senior Member
Apr 26, 2015
52
24
Pszów
HTC 10
Samsung Galaxy S9
Have you ever installed / tested Shamiko hiding?
Shamiko I have barely tested with no success, so I have abandoned further tests. I have now installed safetynet-fix with Displax modifications (safetynet-fix-v2.4.0-MOD_1.2.zip).

I was forced to reinstall the system on my S10e Exynos and Google Wallet did not want to register my payment cards for contactless payments. I had to start figuring out why this is happening since on the same Ambassadii ROM 5.6 system everything was fine before. I didn't know what to do and accidentally came across a hint from qetuol - Senior Member to try to disable "Enforce Denylist". Google Wallet cards I have registered successfully, but only Revolut wouldn't start, saying that I have a rooted phone, which is of course true :) After re-enabling "Enforce Denylist" in Magisk, Google Wallet cards remained, GWallet didn't complain that my phone was rooted unsecured and Revolut went alive at last. I do not know how to explain it. Let me remind you that I have Magisk version 25.2.
 
Last edited:

wtosta

Senior Member
Apr 26, 2015
52
24
Pszów
HTC 10
Samsung Galaxy S9
Maybe you don't understand why we hide root?
Of course, I'm not as knowledgeable about Magisk as you are. However, as far as I know, hiding the root is for the purpose of preventing secured (e.g. banking) applications from "seeing" that the device is rooted, because with root permissions, userspace can access the phone's system partition and do various things that could potentially put user data at risk in e.g. banking applications. However, I don't know what the "Enforce Denylist" option in Magisk is exactly for since there are deny lists to hide the root for applications that you specify.
 

pndwal

Senior Member
Shamiko I have barely tested with no success, so I have abandoned further tests. I have now installed safetynet-fix with Displax modifications (safetynet-fix-v2.4.0-MOD_1.2.zip).

I was forced to reinstall the system on my S10e Exynos and Google Wallet did not want to register my payment cards for contactless payments. I had to start figuring out why this is happening since on the same Ambassadii ROM 5.6 system everything was fine before. I didn't know what to do and accidentally came across a hint from qetuol - Senior Member to try to disable "Enforce Denylist". Google Wallet cards I have registered successfully, but only Revolut wouldn't start, saying that I have a rooted phone, which is of course true :) After re-enabling "Enforce Denylist" in Magisk, Google Wallet cards remained, GWallet didn't complain that my phone was rooted unsecured and Revolut went alive at last. I do not know how to explain it. Let me remind you that I have Magisk version 25.2.
Magisk version won't matter to GPay/Wallet... It does detect root also (specifically contactless setup component), but being Google it does minimal checks... DenyList is enough to hide root for GPay/Wallat as I said...

Shamiko is proper root hiding however (read designed to hide root; denylist just isn't...) Installing that, rebooting, then disabling denylist will not effect GPay/Wallet at all, but it will hide root from many more banks that denylist will...

Of course, disabling denylist without having a root hiding app installed and active first will break GPay/Wallet... 😬 PW
 
  • Like
Reactions: rogerinnyc

rogerinnyc

Senior Member
Feb 1, 2006
340
142
OnePlus 9 Pro
Just adding my experience to this thread, FWIW. On a OnePlus 9 Pro, rooted, Android 13 stock, and using the official Magisk 26.1. All I have installed is Shamiko 0.7 -- no Universal Safety Net Fix, no MagiskHide Props Config. In Magisk settings, Zygisk is enabled (as is required by Shamiko), but not Enforce Deny List. My Configure DenyList includes Google Wallet and Google Play Store, but not Google Play Services. With that configuration, Google Wallet has been working consistently. I can't speak to the various banking apps -- but I use Chase with this configuration (but the setup to get it working is not straight-forward, involving using an older apk version initially, and functionality for secure messages doesn't always work).

I did have a problem with opening Wallet after a reboot and getting a pop up warning that your device does not meet security requirements, but I could simply dismiss that and Wallet would still work (and "tap to pay setup" would show "Your phone meets security requirements" still). I think that may have been Magisk taking some time to load. I've gone into Battery settings for Magisk and enabled it both to run in the background and to autolaunch and that issue hasn't (yet) re-occurred.

Interestingly, with this configuration, using YASNAC (Yet Another SafetyNet Attestation Checker), my device would fail both Basic Integrity and CTS Profile Match, even with Google Wallet working. Once I added Universal Safety Net Fix 2.4, YASNAC would pass my device. So far, no ill effects from having both Shamiko and USNF installed and running. But Shamiko alone was sufficient for Google Wallet purposes.

YMMV.

P.S. I should add that once you have the Magisk/Module set up you want, you should clear cache (and, I believe but am not certain it's needed, data) for Google Play Store and Google Play Services and and Google Wallet and reboot.
 

wtosta

Senior Member
Apr 26, 2015
52
24
Pszów
HTC 10
Samsung Galaxy S9
Thanks to pndwal's suggestions, I confirm what rogerinnyc wrote above. On my S10e I'm using Ambassadii ROM 5.6 and Magisk 26.1 the Zygisk option is enabled. I set denials for GPay/Wallet, Google Play Services, banking applications and the Allegro application (a popular shopping platform in Poland, something like eBay). Also, I have the safetynet-fix-v2.4.0-MOD_1.2 module installed in Magisk. Without the Shamiko module installed in Magisk and without Enforce Deny List enabled, a strange thing happens. Namely, the GPay/Wallet application worked, but the banking applications detected the root. When Enforce Deny List was enabled, banking applications did not detect the root, but GPay/Wallet stopped working and showed that the device does not comply with security rules. Only the installation of the Shamiko module with the DISABLED Enforce Deny List in Magisk solved the problem. Both GPay/Wallet works and other banking apps don't see root. I did not tested removal of safetynet-fix-v2.4.0-MOD_1.2 module and leaving Shamiko module alone anymore. But my current combination of modules works for me. Thank you, Dear Friends, once more for your hints.
 

pndwal

Senior Member
Thanks to pndwal's suggestions, I confirm what rogerinnyc wrote above. On my S10e I'm using Ambassadii ROM 5.6 and Magisk 26.1 the Zygisk option is enabled. I set denials for GPay/Wallet, Google Play Services, banking applications and the Allegro application (a popular shopping platform in Poland, something like eBay). Also, I have the safetynet-fix-v2.4.0-MOD_1.2 module installed in Magisk. Without the Shamiko module installed in Magisk and without Enforce Deny List enabled, a strange thing happens. Namely, the GPay/Wallet application worked, but the banking applications detected the root.
I believe GPay/Wallet would usually fail after some time unless you still pass Play Integrity deviceIntegrity verdict because ROM integrates SNF or it's own spoofs for this...

It's not surprising bank apps fail without denylist (they actively search for root) / Shamiko (proper hiding for traces of Zygisk etc)...
When Enforce Deny List was enabled, banking applications did not detect the root, but GPay/Wallet stopped working and showed that the device does not comply with security rules. Only the installation of the Shamiko module with the DISABLED Enforce Deny List in Magisk solved the problem. Both GPay/Wallet works and other banking apps don't see root. I did not tested removal of safetynet-fix-v2.4.0-MOD_1.2 module and leaving Shamiko module alone anymore. But my current combination of modules works for me. Thank you, Dear Friends, once more for your hints.
Having Play Services, specifically the droid guard/attestation process com.google.android.gms.unstable in active denylist breaks Zygisk based USNF builds (note, it will remove these from denylist on next boot for this reason) because DenyList reverts/prevents Magisk modifications in listed processes unlike old MagishHide. (It's really now a development tool, not a hiding tool.) In this case USNF injects code in gms to register a fake keystore to cause the fallback to basic attestation that's it's key function, so we can't hide root front gms using Denylist... Shamiko on the other hand is a proper hiding module and simply uses denylist (for convenience) as a hidelist, so it doesn't break USNF in this case...

Zy-USNF builds hide root from gsm processes itself, so they shouldn't be added in denylist anyway... This should be done to pass device integrity verdicts if you use pre-Android 8, devices with broken keymaster implementations or revoked keys, or when ROM integrates it's own SNF/spoofing, and USNF is not used/needed but never with Zy-USNF.

GPay/Wallet needs passing PI deviceIntegrity and you need to check this is passing with a Play Integrity checker app... You'll see this fail as soon as denylist is enforced...

Bank apps on the other hand often employ their own checks for traces of root and some don't check deviceIntegrity. Some only check deviceIntegrity and some do both...

Hope it helps your understanding of this.

🤠 PW
 

wtosta

Senior Member
Apr 26, 2015
52
24
Pszów
HTC 10
Samsung Galaxy S9
GPay/Wallet needs passing PI deviceIntegrity and you need to check this is passing with a Play Integrity checker app... You'll see this fail as soon as denylist is enforced...
It happens exactly as you said. So denylist enforcement in Magisk should be disabled. Shamiko module properly hides the root for all the rest bankig/shopping apps :)
 

nicky-xda

Senior Member
Jan 23, 2010
457
64
I have an issue with only 1 german bank app: Hanseatic Bank Secure.

It starts normally without issues on my phone xiaomi mi9 / magisk 26.1 / shamiko 0.7.161 / safet_netfix2.4.mod1.2
On my second mi9, which is the same device with exactly the same installation, it will not start and shows: rooted device.

I've tried to dis-/enable "enforce denylist", hide magisk, different older versions of the app, nothing helps.

What could be the reason for this strange thing?
 
Last edited:

wtosta

Senior Member
Apr 26, 2015
52
24
Pszów
HTC 10
Samsung Galaxy S9
I have an issue with only 1 german bank app: Hanseatic Bank Secure.

It starts normally without issues on my phone xiaomi mi9 / magisk 26.1 / shamiko 0.7.161 / safet_netfix2.4.mod1.2
On my second mi9, which is the same device with exactly the same installation, it will not start and shows: rooted device.

What could be the reason for this strange thing?
I would start by clearing the memory of Google Play Services and your Hanseatic Bank Secure. Then I would try to register it again in your phone. Of course, Magisk settings and modules should be set up as was written in posts above. Of course in Magisk your banking app must be checked in the Zygisk denial list with all components ticked. Also it is good idea to hide a Magisk app by renaming it (there is an option in Magisk settings). You may also try to install a Play Integrity API Checker from Play store. It is a good prognostic for that you have set up things correctly. Your device should meet device integrity and basic integrity. Strong integrity of course will fail as your device has unlocked bootloader and it is a rooted phone.
 
Last edited:

pndwal

Senior Member
Just adding my experience to this thread, FWIW. On a OnePlus 9 Pro, rooted, Android 13 stock, and using the official Magisk 26.1. All I have installed is Shamiko 0.7 -- no Universal Safety Net Fix, no MagiskHide Props Config. In Magisk settings, Zygisk is enabled (as is required by Shamiko), but not Enforce Deny List. My Configure DenyList includes Google Wallet and Google Play Store, but not Google Play Services. With that configuration, Google Wallet has been working consistently. I can't speak to the various banking apps -- but I use Chase with this configuration (but the setup to get it working is not straight-forward, involving using an older apk version initially, and functionality for secure messages doesn't always work).

I did have a problem with opening Wallet after a reboot and getting a pop up warning that your device does not meet security requirements, but I could simply dismiss that and Wallet would still work (and "tap to pay setup" would show "Your phone meets security requirements" still). I think that may have been Magisk taking some time to load. I've gone into Battery settings for Magisk and enabled it both to run in the background and to autolaunch and that issue hasn't (yet) re-occurred.

Interestingly, with this configuration, using YASNAC (Yet Another SafetyNet Attestation Checker), my device would fail both Basic Integrity and CTS Profile Match, even with Google Wallet working. Once I added Universal Safety Net Fix 2.4, YASNAC would pass my device. So far, no ill effects from having both Shamiko and USNF installed and running. But Shamiko alone was sufficient for Google Wallet purposes.

YMMV.

P.S. I should add that once you have the Magisk/Module set up you want, you should clear cache (and, I believe but am not certain it's needed, data) for Google Play Store and Google Play Services and and Google Wallet and reboot.
Interesting that you can still use contactless despite contactless setup detecting compromised environment... The detection is expected however...

Seems your OnePlus 9 Pro may be one of many OnePlus devices with broken keymaster implementation... Does Momo app say "Broken TEE"? (If it does, TEE OS is not really broken but key based attestation is.) Also, does YASNAC say BASIC for evaluationType?

If this is correct you won't need USNF to trigger fallback to basic attestation; device is already falling back to this due to broken hardware key-backed attestation.

You still need to add Google Play Services to denylist, specifically the droid guard/attestation process com.google.android.gms.unstable and the main process, com.google.android.gms, in order to hide root from gms. Seems this is what you're missing...

You also need a solution to set sensitive props to non-suspicious values. I believe Shamiko includes this function. (If not, MagiskHide Props Config module goes this with nothing configured; MagiskHide sensitive props are adjusted just enable by default.) With Shamiko active (denylist disabled / not enforced) you should now have passing deviceIntegrity. Nb, SafetyNet API is now depreciated; Check deviceIntegrity with Play Integrity API Checker.

The only benefit you were gaining with USNF was that it does hide root from gms, but if you want to keep it instead of adding the GMs processes in denylist manually there should be no issue... It also duplicates the sensitive props adjustments...

Chase have started detecting Zygisk injection... This should start working with new native bridge Zygisk loading (akin to hidable Riru framework/memory hiding) + Shamiko (already supports hiding native bridge based hooking memory) which is currently a WIP (2+ months already) but should be seen in Magisk 27.0... I've put alot about native bridge Zygisk refactoring in Magisk Discussion thread recently...

Chase works in Alpha fork POC for me.

🤠 PW
 
Last edited:
  • Like
Reactions: rogerinnyc

nicky-xda

Senior Member
Jan 23, 2010
457
64
thanks a lot, wtosta!
Play Integrity API Checker & YASNAC both show PASS, resetted Play Services, and the bank app several times already: unfortunately nothing seems to help.
 

rogerinnyc

Senior Member
Feb 1, 2006
340
142
OnePlus 9 Pro
Interesting that you can still use contactless despite contactless setup detecting compromised environment... The detection is expected however...

Seems your OnePlus 9 Pro may be one of many OnePlus devices with broken keymaster implementation... Does Momo app say "Broken TEE"? (If it does, TEE OS is not really broken but key based attestation is.) Also, does YASNAC say BASIC for evaluationType?

If this is correct you won't need USNF to trigger fallback to basic attestation; device is already falling back to this due to broken hardware key-backed attestation.

You still need to add Google Play Services to denylist, specifically the droid guard/attestation process com.google.android.gms.unstable and the main process, com.google.android.gms, in order to hide root from gms. Seems this is what you're missing...

You also need a solution to set sensitive props to non-suspicious values. I believe Shamiko includes this function. (If not, MagiskHide Props Config module goes this with nothing configured; MagiskHide sensitive props are adjusted just enable by default.) With Shamiko active (denylist disabled / not enforced) you should now have passing deviceIntegrity. Nb, SafetyNet API is now depreciated; Check deviceIntegrity with Play Integrity API Checker.

The only benefit you were gaining with USNF was that it does hide root from gms, but if you want to keep it instead of adding the GMs processes in denylist manually there should be no issue... It also duplicates the sensitive props adjustments...

Chase have started detecting Zygisk injection... This should start working with new native bridge Zygisk loading (akin to hidable Riru framework/memory hiding) + Shamiko (already supports hiding native bridge based hooking memory) which is currently a WIP (2+ months already) but should be seen in Magisk 27.0... I've put alot about native bridge Zygisk refactoring in Magisk Discussion thread recently...

Chase works in Alpha fork POC for me.

🤠 PW
Thanks for the info. I need to update my post -- this a.m., Wallet showed that the device was not secure even tho I had not changed anything in my settings. Grr. Tried a whole bunch of variations (with data wipes of gms, play and wallet each time) and ended up with USNF 2.4 enabled, Shamiko 0.7 enabled and MagiskHide Props Config enabled. No GMS in the deny list. Working for now (although yesterday I had secure messages working in Chase and although I can log in with fingerprint and pretty much do everything else, that is not working today).

Device integrity and Basic Integrity passes with Integrity API Checker; YASNAC, evaluating on a BASIC level passes also. I don't have/use Momo, but I found an apk and it seemed to say my environment was broken??

Will report further after I've lived with this configuration for a while (or if it breaks also)

EDIT: The secure message issue in the Chase App was an AdGuard setting; nothing to do with root hiding
 
Last edited:

nicky-xda

Senior Member
Jan 23, 2010
457
64
I have an issue with only 1 german bank app: Hanseatic Bank Secure.

It starts normally without issues on my phone xiaomi mi9 / magisk 26.1 / shamiko 0.7.161 / safet_netfix2.4.mod1.2
On my second mi9, which is the same device with exactly the same installation, it will not start and shows: rooted device.

I've tried to dis-/enable "enforce denylist", hide magisk, different older versions of the app, nothing helps.

What could be the reason for this strange thing?

Very strange case indeed. I know it's a last resort, but maybe all you have left is a clean system reinstall. Good luck with this.

I was able to solve the issue by re-installing magisk in magisk app by "direct install" again.

I installed magisk by patching "boot.img" extracted from my ROM and flashig it in orange fox recovery.
Even if it showed magisk installed correctly something must have failed when flashing in recovery before.

thanks once more for your hints!
 
  • Like
Reactions: wtosta

jimbobmcginty

Senior Member
Apr 23, 2010
126
35
Thanks for the info. I need to update my post -- this a.m., Wallet showed that the device was not secure even tho I had not changed anything in my settings.
I see similar to you. Earlier today I used wallet with NFC to pay, and now wallet tells me "doesn't meet security requirements" - I've changed nothing in between.

Magisk Canary 26101
MagiskHideProps v6.1.2-v137
Shamiko 0.7.1(166)
USNF v2.4.0

Zygisk enabled
Enforce DenyList off
Denylist :
Various bank apps
- Google Play Services / gms
- Google Wallet / walletnfccrel
- Google Services Framework / gsf

I see a weird thing with GSF though, it keeps getting unticked . Any time I open the denylist, it's unticked, even though last time I definitely made sure both gapps and gservices sub-items were ticked
 

zgfg

Senior Member
Oct 10, 2016
9,639
7,501
Redmi K20 / Xiaomi Mi 9T
Xiaomi Mi 11
USNF v2.4.0

I see a weird thing with GSF though, it keeps getting unticked . Any time I open the denylist, it's unticked, even though last time I definitely made sure both gapps and gservices sub-items were ticked
Not weird. Mentioned here and elsewhere that USNF removes GFS from DenyList (it takes care by itself, and it has been that since the beginnings of USNF). You can find how it removes from the USNF scripts

Btw, make sure to use the newer and modded safetynet-fix-v2.4.0-MOD_1.2.zip
 
  • Like
Reactions: jimbobmcginty

jimbobmcginty

Senior Member
Apr 23, 2010
126
35
Installing the modified USNF appears to have fixed it, Wallet is back in action, thanks!
Not weird. Mentioned here and elsewhere that USNF removes GFS from DenyList (it takes care by itself, and it has been that since the beginnings of USNF). You can find how it removes from the USNF scripts

Btw, make sure to use the newer and modded safetynet-fix-v2.4.0-MOD_1.2.zip
 
  • Like
Reactions: zgfg

Top Liked Posts

  • There are no posts matching your filters.
  • 63
    The new Google Play services update caused this.

    Temporary workaround:

    1. Disable Google Pay/Find My Device as Device Administrators in Settings > Security & location > Device Administrators.

    2. Search "Google Play services" in the Settings search bar.

    3. Press the three dots and press "Uninstall previous updates".

    4. Download this update - https://www.apkmirror.com/apk/google-inc/google-play-services/google-play-services-14-7-99-release/
    Pick your needed edition (arm or arm64, etc.), download it and install it.

    5. Disable Background data access for Google Play Services and Google Play in their respective App Info pages.

    6. Download Google Pay from the Play Store.

    7. Set up your cards. Enjoy!

    Never EVER update Google Play services manually, until a Magisk update is available that bypasses the upgraded SafetyNet. Note that Google Play services is responsible for adding/verifying the card, not the Google Pay app! Hence why there seems to be an overlay when adding a card/verifying an existing one.

    Tested Google Pay versions:

    2.79.x-2.83.235070858 - working

    Tested Google Play services versions:

    14.7.99, 16.0.86 - working with Magisk 18.1

    14.8.49-16.x- working with Magisk 18.2 Canary
    33
    This thread is inspired by the PoGo Magisk discussion thread. It's meant to keep the clutter of "Google Pay doesn't work" posts out of the main Magisk threads.

    Please use this to discuss issues with Google Pay and possible solutions.


    There's a working solution here:
    https://forum.xda-developers.com/t/magisk-module-universal-safetynet-fix-2-3-1.4217823/post-87198517


    For general tips on first getting SafetyNet to pass fully, check here:
    https://www.didgeridoohan.com/magisk/MagiskHide#hn_SafetyNet
    29
    Ok. I tried this and it worked on gms 17.1.22, allowing one to add cards and pay in store. Warning YMMV, but this is the process I did to get this working. One caveat is that Google pay does not register the "recent transactions" on the Google pay app. Another caveat is that I suspect users will have to reverse some step if gms is updated and then reapply, but this still needs to be confirmed

    Without further ado, here is my process:

    1) download a SQL database editor. I used

    https://play.google.com/store/apps/details?id=com.tomminosoftware.sqliteeditor&hl=en_US

    2) download a terminal emulator program. I used terminus but any terminal emulator should work.

    3) make sure Google pay is forced close, if it is open.

    4) open SQL editor. Navigate to /data/data/com.google.android.gms/databases

    5) open dg.db

    6) change any value that lists "attest" in the name (first column) to 0 in the third column. Mine was showing a value of 10 in the third column for each of these values. (Column c for sqlite databse editor I used)

    7) open the terminal emulator.

    8) get root access (su)

    9) cd /data/data/com.google.android.gms/databases

    10) type: chmod 440 dg.db
    This makes dg.db read only (for owner and group, and no access for world.)

    11) reboot

    I suspect when gms is updated, one will have to go back to steps 10 and 11 and chmod 660 dg.db to allow new keys to be written to the database, and then go back and redo all these steps to reset the attestation values back to 0.

    If there is still an error, verify in sqlite database editor that all attest release keys values in dg.db are 0 when dg.db is read only (owner and group).

    Again, YMMV but this worked for me, so I give it back to the community now.

    Edit: recent activities did show up soon afterwards for the payment method.

    Cheers,
    B.D.
    28
    The app is finally public! (thanks Google for taking a week to approve this 🤦)
    I made it beta testing since I haven't tested it on much devices. If you find any problem, please open an issue here and I'll take a look at them once I return from vacation.


    Source code:

    If you are curious, the possible outcomes I've seen are:
    • 3 ticks (unrooted samsung)
    • tick/tick/x (unrooted redmi note 4 with unlocked bootloader)
    • x/tick/x (my rooted a11 op7t)
    23
    UPDATE 1/8/2022
    This app is officially discontinued in favor of a new app I published on Play Store. Read more here:

    ====================
    ORIGINAL MESSAGE:

    I just made this simple app which tells you if your device passes the new Play Integrity API (which is presumably what Google Pay and Play Store use to detect root now). If you don't trust random apks from the internet feel free not to use this. I'll upload the source code at a later time since it's very junk now (probably on github).
    You can use it to play around and see if you manage to get it to pass without having to mess with Google Pay. There are screenshots of the 2 possible outputs (pass screenshot is from an online emulator).
    Also I didn't test it much since I don't have many devices that can pass. Hope it works fine 🤞

    Hope this helps someone find a solution :)

    EDIT:
    Here is a quote from Google of what exactly "Does not meet device integrity" mean:
    The app is running on a device that has signs of attack (such as API hooking) or system compromise (such as being rooted), or the app is not running on a physical device (such as an emulator that does not pass Google Play integrity checks).
    ...
    If you are having problems with your testing device meeting device integrity, make sure the factory ROM is installed (for example, by resetting the device) and that the bootloader is locked.