[Discussion] Google Pay Magisk Discussion Thread

[Minecraftitsover90]

I

Please confirm that you are actually using a @Displax USNF mod build... It's still not clear although it's usually needed for deviceIntegrity w/ A11+...

Next, consider and say what changes you made between having and loosing deviceIntegrity... Nb. Even when nothing is wrong with a setup any longer, clearing Google Play Services data is sometimes (often?) needed to restore deviceIntegrity etc... Some users have even needed to disable USNF module (official or forked), reboot, enable and boot again to fix...

Seems you did tick Google Play Services (gms) processes... See discussion above... Perhaps screenshot w/ MEETS_DEVICE_INTEGRITY missing was taken before rebooting (ie gms in denylist not yet removed and still breaking the PI fix)?... Could be an added module etc too... PW

I am now using a @Displax USNF mod build and also I think I lost device integrity when I went to add a card in Google Pay/Google Wallet maybe when it went to contacting your bank or when I clicked on set up payment card.

 

[pndwal]

That is one of the reasons I wrote it the way I did.

To try and prevent conficts.​

Since USNF is not affected when the denylist is not enforced, just ignore it.
Let what ever the user adds to the list stay there, do not mess with it.

Before Allow modifying denylist without enforcement, the denylist was only accessible when enforcing.

To be precise, Enforce DenyList needed to be disabled to edit/modify it... I think it was accessible as Shamiko was already using it as a hidelist when not enforced...

The original command would only run when enforcing and error out when not enforcing.
Once the denylist was accessible when not enforcing, the command would run regardless of denylist status.

Ah... So no modifications were allowed before Allow modifying denylist without enforcement even at boot-time! (ie magisk --denylist DenyList Config CLI rm PKG [PROC] wouldn't work when not enforced?)... I hadn't understood this; thanks!

"Since there is no need or reason to remove gms from the Denylist when not enforcing, why remove it?​

Use a scalpel instead of a machete."​

Fair enough... I was considering having dual root hiding methods (Shamiko + inbuilt USNF) applied to gms could cause issues and be a reason... If removal was 'erroring out' as you state below, we would have had dual hiding occuring w/ Shamiko before Allow modifying denylist without enforcement without issues anyway...

The magisk --denylist status command returns true (0) when enforcing.
When not enforcing, the command returns an error (1).

Is second case really an error or just status?
In terminal at least now I don't see 'true (0)' or 'error (1)', only 'Denylist is enforced' and 'Denylist is not enforced' respectively...

The USNF module will load and run just fine even if you are enforcing the denylist and include gms.
The module will just be unloaded every time gms is called.

Ah, @kdrag0ns statement 'never load' needed qualifying... Thanks... Seems means 'never load in processes in (enforced) denylist' in reality... (dev speak / user speak?)

FWIW, I think denylist entries mean Magisk "reverts all changes it had done" (as you cite below) immediately, and also "denies further modifications" in these processes, ie it does 'never load' as he says in listed processes rather than needing to be "unloaded every time gms is called"... Praps I'm missing something here to... another fine point anyway...

So guess this still means CTS Profile Match should have been failing w/ gms in denylist... How did I miss this?(!)... Wait... I'll test again...

Yup, I'd missed it previously! ... w/ droidguard (attestation) process (com.google.android.gms.unstable) in denylist and DenyList enforced i get this:

Nb. Selecting main gms process (com.google.android.gms) does not affect the result on my device... Unless droidguard process is added RN8T w/ A10 MIUI passes deviceIntegrity... Guess on A11+ devices where Magisk is not in /sbin com.google.android.gms in denylist may also break USNF...

When enforcing the denylist, every time a process in the list is called..
Magisk tries to "get out of the way" by unloading and reverting as much of itself as possible.
No modules will be active to the process while it is called.

Yup... But perhaps enforcing denylist means Magisk modifications 'are never loaded' in called/spawned processes rather than needing unloading as @kdrag0n parlance suggests...

This seems to be what John was implying by "Magisk denies further modifications [after a process is added to denylist] and reverts all changes it had done [before it was added]" also... - Insertions are mine, but I think I'm interpreting this correctly(?).

When not enforcing the denylist, Magisk has no use for the denylist.
It is about as important to Magisk as your grocery shopping list.

Quite.

Took me a little bit to find where I read the "get out of the way" part.

Seems like mine, your photographic memory needs developing... ()

... More to follow... PW

 

[pndwal]

Continued...

State of Magisk: 2021

Spoiler: Bye, MagiskHide. Long Live MagiskHide

That being said, I strongly value the ability for apps to fully “opt-out” of modding, and it is important to me that Magisk is able to “get out of the way”, so a minor subset of the MagiskHide infrastructure will remain. Users will be able to assign a denylist of processes where Magisk denies further modifications and reverts all changes it had done. Magisk will not spoof/alter/manipulate any non-Magisk related signals or traces to circumvent any device state detection.

And this really sums up the whole need for
"magisk: Remove Play Services from DenyList …
The Zygisk module will never load if GMS is in the DenyList..."

I did envisage issues with multiple hiding solutions operating on one process as covered above, but these haven't been demonstrated anywhere...

However while denylist does hide by virtue of 'Magisk getting out of the way', it actually prevents Magisk modifications from affecting selected processes at all, unlike. hiding solutions, so any Zygisk based injection of code into a forked zygote process that loads and runs a new app's code cannot occur for instance.

Since USNF's key function works this way it must fail when gms droidguard process is in (enforced) denylist:

This module uses Zygisk to inject code into the Play Services process and register a fake keystore provider that overrides the real one. When Play Services attempts to use key attestation, it throws an exception and pretends that the device lacks support for key attestation. This causes SafetyNet to fall back to basic attestation...

I believe that the various targeted prop changes needed to trigger hardware based verdict enforcement bypasses in S/N and PI also use Zygisk, so these functions will fail also...

I have to agree that it's the nature of denylist that necessitates the removal of at least the gms droidguard process from denylist (although I still think merely instructing users is to do this manually where needed is all that is needed and would actually cause less confusion)...

Anyway, thanks for helping me properly connect modification denial with the reason for magisk: Remove Play Services from DenyList commit.

Only after..

1. They make a post claiming they followed the instructions and it does not work.
   Normally adamant that it is the module's fault not their own.

1. 
   
2. Someone points out they are enforcing the denylist.
   Even though Shamiko notes that it is not working because denylist is enforcing.

I didn't mean to suggest that Shamiko users were dumb enough to enforce denylist... USNF would remove gms processes on next boot anyway...

Shamiko should really note somewhere that hijacked denylist really = hidelist, if only to create an excuse to fall about laughing at the confused gringo-user posts suddenly appearing in LSP TG threads everywhere...

1. 
   
2. 
   
3. Someone points out they are enforcing the denylist and include gms in the denylist.
   "I have the USNF module installed and I still fail SafetyNet."

Same here.

PW

 

[pndwal]

I am now using a @Displax USNF mod build and also I think I lost device integrity when I went to add a card in Google Pay/Google Wallet maybe when it went to contacting your bank or when I clicked on set up payment card.

That would be strange...

Did you do the wipe and try again?... disable USNF, reboots?... Removed all gms processes from denylist?...

Try the above again with ALL modules other than USNF_mod disabled... Ensure Zygisk = Yes in Magisk App home screen... PW

 

[ipdev]

To be precise, Enforce DenyList needed to be disabled to edit/modify it... I think it was accessible as Shamiko was already using it as a hidelist when not enforced...

Ah... So no modifications were allowed before Allow modifying denylist without enforcement even at boot-time! (ie magisk --denylist DenyList Config CLI rm PKG [PROC] wouldn't work when not enforced?)... I hadn't understood this; thanks!

You originally had it backwards but, looks like you figured it out.
Denylist had to be enabled (enforced) before you could edit/modify it.

Not sure when Shamiko actually became to be in existence.

or when I started using Shamiko. ​

The oldest release on GitHub is v0.3.0 and that is dated a few days after John committed the change for Magisk's denylist.
The Shamiko release notes make note of working around it.

3. Request Magisk 23017+, which allows us to strip Java daemon and change denylist regardless of enforcement status​

Is second case really an error or just status?

It is an error.

To complicate the answer.
The "status" in magisk's database when enforcing the denylist is 1.​

In terminal at least now I don't see 'true (0)' or 'error (1)', only 'Denylist is enforced' and 'Denylist is not enforced' respectively...

$? is the return (exit) value of the last command.

bonito:/ $ su
bonito:/ # 
bonito:/ # magisk --denylist status
Denylist is enforced
bonito:/ # echo $?
0
bonito:/ # magisk --denylist status
Denylist is not enforced
1|bonito:/ # echo $?
1
bonito:/ #

Notice the command line changes after checking when not enforcing.
It includes the exit value 1|bonito:/ # because the command did not return 0 (successful).

This is the reason why the if/then statement works.
if magisk --denylist status; then
Enforcing will return as true because the command exits with 0 (success).
Not enforcing will return as false because the command exits with 1 (error).

Otherwise this would have had to been more complicated. ​

Ah, @kdrag0ns statement 'never load' needed qualifying... Thanks... Seems means 'never load in processes in (enforced) denylist' in reality... (dev speak / user speak?)

FWIW, I think denylist entries mean Magisk "reverts all changes it had done" (as you cite below) immediately, and also "denies further modifications" in these processes, ie it does 'never load' as he says in listed processes rather than needing to be "unloaded every time gms is called"... Praps I'm missing something here to... another fine point anyway...

So guess this still means CTS Profile Match should have been failing w/ gms in denylist... How did I miss this?(!)... Wait... I'll test again...

Yup, I'd missed it previously! ... w/ droidguard (attestation) process (com.google.android.gms.unstable) in denylist and DenyList enforced i get this:
View attachment 5782191
Nb. Selecting main gms process (com.google.android.gms) does not affect the result on my device... Unless droidguard process is added RN8T w/ A10 MIUI passes deviceIntegrity... Guess on A11+ devices where Magisk is not in /sbin com.google.android.gms in denylist may also break USNF...

When enforcing the denylist, I use what was MagiskHide for gms.
This only works for devices that do not suport hardware Attesatation.

#define SNET_PROC    "com.google.android.gms.unstable"
#define GMS_PKG      "com.google.android.gms"

Remove all non-Magisk hiding code · topjohnwu/Magisk@003fea5

Magisk no longer interferes with any signals/info that were not created or caused by Magisk itself.

github.com

    // Add SafetyNet by default
    add_hide_set(GMS_PKG, SNET_PROC);

    // We also need to hide the default GMS process if MAGISKTMP != /sbin
    // The snet process communicates with the main process and get additional info
    if (MAGISKTMP != "/sbin")
        add_hide_set(GMS_PKG, GMS_PKG);

Remove all non-Magisk hiding code · topjohnwu/Magisk@003fea5

Magisk no longer interferes with any signals/info that were not created or caused by Magisk itself.

github.com

I set this as a function in my scripts if I need it.

set_default_list() {
    magisk --denylist add com.google.android.gms com.google.android.gms.unstable
    if [[ $(magisk --path) != /sbin ]]; then
        magisk --denylist add com.google.android.gms com.google.android.gms
    fi
}

usnf/customize.sh at testing · ipdev99/usnf

Universal fix for Google SafetyNet on Android devices with hardware attestation and unlocked bootloaders. - usnf/customize.sh at testing · ipdev99/usnf

github.com

Yup... But perhaps enforcing denylist means Magisk modifications 'are never loaded' in called/spawned processes rather than needing unloading as @kdrag0n parlance suggests...

This seems to be what John was implying by "Magisk denies further modifications [after a process is added to denylist] and reverts all changes it had done [before it was added]" also... - Insertions are mine, but I think I'm interpreting this correctly(?).

Somethings still exist.
Seems boot-time changes like prop values and such are global and not reverted when a process on the denylist is called.
Devices that do not support Hadrware Attestation, you can pass SN/PI with prop changes during boot while including gms in the enforcing denylist.

Cheers.

 

[ipdev]

Seems like mine, your photographic memory needs developing... ()

---

I am more..




Cheers.

 

[Minecraftitsover90]

That would be strange...

Did you do the wipe and try again?... disable USNF, reboots?... Removed all gms processes from denylist?...

Try the above again with ALL modules other than USNF_mod disabled... Ensure Zygisk = Yes in Magisk App home screen... PW

nvm i got past that stage
unfortunately i got the Couldn't finish card setup for pay contactless
to resolve this, you'll need to contact your bank

 

[pndwal]

You originally had it backwards but, looks like you figured it out.
Denylist had to be enabled (enforced) before you could edit/modify it.

Nah... Didn't... I did simplify the overly complex sentence, but said the same thing. Knew this well as had to disable enforcement to configure denylist (now really hidelist) for Shamiko for a while...

Not sure when Shamiko actually became to be in existence.

I posted about Shamiko POC from a post by @nu11ptr in Alpha TG discussion (now hidden as "街角LycoReco的處刑之吻", and recently purged) on Dec 2, 2021:
https://xdaforums.com/t/magisk-general-support-discussion.3432382/post-86032113
... Posted re. first public release on Dec 4 here:
https://xdaforums.com/t/magisk-general-support-discussion.3432382/post-86042643
Originally needed to build Magisk with Shana's XHook clear commit or use Shana / Canyie Metagisk build... TJW merged this commit on Dec 14 2021 here:
https://github.com/topjohnwu/Magisk/pull/5010
making official Magisk compatible w/ Shamiko in Canary 23016 on Dec 15 2021... Essentially only Zygisk hiding then... (Of course there was likely discussion about this, and Shana was most likely already in John's Magisk Slack group; she certainly is now)... We can only speculate...

The Allow modifying denylist without enforcement commit was built in Canary 23017 on Jan 20 this year... vvb2060 made the PR: https://github.com/topjohnwu/Magisk/pull/5235/commits/e44a875345e1265a8455df85093208e746280147
...

or when I started using Shamiko. ​

Can't help you here...

The oldest release on GitHub is v0.3.0 and that is dated a few days after John committed the change for Magisk's denylist.
The Shamiko release notes make note of working around it.

3. Request Magisk 23017+, which allows us to strip Java daemon and change denylist regardless of enforcement status​

... There was no GitHub release page till it was added to LSPosed public repos by Shana on 20 Jan this year, same date as Canary 23017 release... ; Earlier releases were all passed on from TG... GitHub page made things much easier in the face of XDA policing no TG as file source policy (we couldn't post proper links till then)...

So yes, Shamiko (a Canyie initiative) became mature for most users from 23017 but was compatible from 23016 (some tried it w/ 23015 before this too, but didn't succeed of course), so a number of members here were using it some 6 weeks before Allow modifying denylist without enforcement...

It is an error.

To complicate the answer.​

The "status" in magisk's database when enforcing the denylist is 1.​

$? is the return (exit) value of the last command.

bonito:/ $ su
bonito:/ #
bonito:/ # magisk --denylist status
Denylist is enforced
bonito:/ # echo $?
0
bonito:/ # magisk --denylist status
Denylist is not enforced
1|bonito:/ # echo $?
1
bonito:/ #

Notice the command line changes after checking when not enforcing.
It includes the exit value 1|bonito:/ # because the command did not return 0 (successful).

This is the reason why the if/then statement works.
if magisk --denylist status; then
Enforcing will return as true because the command exits with 0 (success).
Not enforcing will return as false because the command exits with 1 (error).

Otherwise this would have had to been more complicated. ​

Thanks for clarifying / covering this.. I think I've got it now! ... It's complex enough all right...

When enforcing the denylist, I use what was MagiskHide for gms.
This only works for devices that do not suport hardware Attesatation.

#define SNET_PROC    "com.google.android.gms.unstable"
#define GMS_PKG      "com.google.android.gms"

Remove all non-Magisk hiding code · topjohnwu/Magisk@003fea5

Magisk no longer interferes with any signals/info that were not created or caused by Magisk itself.

github.com

    // Add SafetyNet by default
    add_hide_set(GMS_PKG, SNET_PROC);

    // We also need to hide the default GMS process if MAGISKTMP != /sbin
    // The snet process communicates with the main process and get additional info
    if (MAGISKTMP != "/sbin")
        add_hide_set(GMS_PKG, GMS_PKG);

Remove all non-Magisk hiding code · topjohnwu/Magisk@003fea5

Magisk no longer interferes with any signals/info that were not created or caused by Magisk itself.

github.com

I set this as a function in my scripts if I need it.

set_default_list() {
    magisk --denylist add com.google.android.gms com.google.android.gms.unstable
    if [[ $(magisk --path) != /sbin ]]; then
        magisk --denylist add com.google.android.gms com.google.android.gms
    fi
}

usnf/customize.sh at testing · ipdev99/usnf

Universal fix for Google SafetyNet on Android devices with hardware attestation and unlocked bootloaders. - usnf/customize.sh at testing · ipdev99/usnf

github.com

... Good stuff!...

Somethings still exist.
Seems boot-time changes like prop values and such are global and not reverted when a process on the denylist is called.

You mean these still exist?... But the point is they're not 'unloaded' for a process/when a process is called either!

...But Zygisk modules that run code in a process's zygote (and other modifications?) must never load (as @kdrag0n states) for processes in the list...

Just saying I don't think this meant

The USNF module ... will just be unloaded every time gms is called.

or

... every time a process in the list is called..
Magisk tries to "get out of the way" by unloading and reverting as much of itself as possible...

... Rather, it seems @kdrag0n's statement that the module will 'never load' is correct for processes in (enforced) denylist'...

I think the statement that Magisk "reverts all changes it had done" applies immediately after a process is added to denylist (since it takes effect immediately, without reboot) rather than to unloading 'every time a process in the list is called'...

Devices that do not support Hadrware Attestation, you can pass SN/PI with prop changes during boot while including gms in the enforcing denylist.

Yup...

... You don't need a good memory anyway... just a keen nose...

... Regards, PW

 

[DineshValor]

I'm using rooted android 10 with Safetynet Pass & Play Store -Certified, but I'm still not able to activate tap to pay on Paytm app.


It's gives me a error - "This functionality is not available due to security concerns with your device."

How can I fix it?

Same issue with me? Did any solution found yet?

 

[pndwal]

Same issue with me? Did any solution found yet?

Of course... Read back here a bit...

SafetyNet is depreciated and Google Pay/Wallet has migrated to new Play Integrity API ... You'll need to be passing deviceIntegrity verdict...

Also, Play Protect certification remains dependant on old S/N API at least for devices w/o new separated Google Play Protect Service, so that doesn't indicate that PI deviceIntegrity is passing for these devices... Latest USNF module has just added fixes for devices that need bypasses for the extra prop based hardware attestation enforcement the Play Integrity API adds however...

PW

 

[BesoC]

Latest USNF module has just added fixes for devices that need bypasses for the extra prop based hardware attestation enforcement the Play Integrity API adds however...

Hi. Do you mean this one - safetynet-fix 2.4.0 from kdrag0n? It doesn't work for my RideDroid A13, even with MagiskHideProps

 

[AndrzejDwo]

Hi. Do you mean this one - safetynet-fix 2.4.0 from kdrag0n? It doesn't work for my RideDroid A13, even with MagiskHideProps

unfortunately 2.4.0 by kdragon doesn't work for me, I have to use 2.3.1 Displax mod, maybe it's the same case for you.

 

[BesoC]

unfortunately 2.4.0 by kdragon doesn't work for me, I have to use 2.3.1 Displax mod, maybe it's the same case for you.

I did tried to use it - Displax v2.3.1-MOD_2.1. With it, the message box 'device does not meet security requirements...' does not appear anymore. However, in menu -> Tap to pay setup, there is still a message "Phone does not meet security requirements'

 

[AndrzejDwo]

I did tried to use it - Displax v2.3.1-MOD_2.1. With it, the message box 'device does not meet security requirements...' does not appear anymore. However, in menu -> Tap to pay setup, there is still a message "Phone does not meet security requirements'

you would have to describe your full setup if you want people to be able to help you. which magisk you use, if deny list is enforced and gpay added into the list, if your device meets basic integrity etc etc etc

 

[BesoC]

you would have to describe your full setup if you want people to be able to help you. which magisk you use, if deny list is enforced and gpay added into the list, if your device meets basic integrity etc etc etc

By all means.

• Phone is OnePlus 6T, RiceDroid 10.1, build date: January 17th, Android 13.
• Magisk 25.2, hidden and renamed with following modules:

• Zygisk with enforced DenyList of all google apps and services installed on the phone:
  
  
• SE policy set to permissive

Anything else I've missed?

 

[AndrzejDwo]

Anything else I've missed?

you missed play integrity check result. the other thing is that you have too many apps on deny list imo, this might result with the opposite result than expected, also you don't need magisk hide props when you use usnf mod by displax, and the last but not least - would be good to switch to ENFORCING SE LINUX if possible, i never tried to setup Gwallet on permissive tbh.

cheers

 

[pndwal]

By all means.

• Phone is OnePlus 6T, RiceDroid 10.1, build date: January 17th, Android 13.
• Magisk 25.2, hidden and renamed with following modules:

View attachment 5817067View attachment 5817073

• Zygisk with enforced DenyList of all google apps and services installed on the phone:
  View attachment 5817055
• SE policy set to permissive

Anything else I've missed?

Yup... Try standard setup; remove ALL things Google from denylist other than G Pay/Wallet and try official 2.4.0 again... remove MHPC also...

AFAIK, PI deviceIntegrity cannot pass w/ selinix set to permissive.. Just don't do that!!! (At least say why you want/have that.)

Or is permissive selinux set by ROM?... Nb. permissive allows Devs to troubleshoot/fix major issues with a ROM and bypasses many of them... ROMs released w/ permissive set should be considered insecure, experimental and unsuitable for daily use...

Check have PI deviceIntegrity in Play Integrity API Checker; if so it's job done... Or move back to @Displax mod/fork...

Nb. Even when nothing is wrong with a setup any longer, clearing Google Play Services data is sometimes (often?) needed to restore deviceIntegrity etc... Some users have even needed to disable USNF module (official or forked), reboot, enable and boot again to fix...

Clearing Play Store data and/or Play Protect Services data if it exists (A12+?) may also be needed to restore Play Protect 'Device is certified' in Play Store Settings, About... This will affect whether Google Pay and other apps calling S/N or PI APIs appear in the Store

Once PI deviceIntegrity is restored / passing, Google Pay/Wallet security requirements may pass again after some days (could take a week!) if simply left... Clearing Google Play Services and Google Pay/Wallet data will fix this immediately but you will need to set up cards again... Nb. Be sure to reboot immediately after clearing Google Pay/Wallet data (before opening app for first time) to avoid issues persisting (eg. app works but Activity list fails to populate)...

PW

 

[BesoC]

Yup... Try standard setup; remove ALL things Google from denylist other than G Pay/Wallet and try official 2.4.0 again... remove MHPC also...

AFAIK, PI deviceIntegrity cannot pass w/ selinix set to permissive.. Just don't do that!!! (At least say why you want/have that.)

Or is permissive selinux set by ROM?... Nb. permissive allows Devs to troubleshoot/fix major issues with a ROM and bypasses many of them... ROMs released w/ permissive set should be considered insecure, experimental and unsuitable for daily use...

Check have PI deviceIntegrity in Play Integrity API Checker; if so it's job done... Or move back to @Displax mod/fork...

Nb. Even when nothing is wrong with a setup any longer, clearing Google Play Services data is sometimes (often?) needed to restore deviceIntegrity etc... Some users have even needed to disable USNF module (official or forked), reboot, enable and boot again to fix...

Clearing Play Store data and/or Play Protect Services data if it exists (A12+?) may also be needed to restore Play Protect 'Device is certified' in Play Store Settings, About... This will affect whether Google Pay and other apps calling S/N or PI APIs appear in the Store

Once PI deviceIntegrity is restored / passing, Google Pay/Wallet security requirements may pass again after some days (could take a week!) if simply left... Clearing Google Play Services and Google Pay/Wallet data will fix this immediately but you will need to set up cards again... Nb. Be sure to reboot immediately after clearing Google Pay/Wallet data (before opening app for first time) to avoid issues persisting (eg. app works but Activity list fails to populate)...

PW

you missed play integrity check result. the other thing is that you have too many apps on deny list imo, this might result with the opposite result than expected, also you don't need magisk hide props when you use usnf mod by displax, and the last but not least - would be good to switch to ENFORCING SE LINUX if possible, i never tried to setup Gwallet on permissive tbh.

cheers

OK.

• Removed MHPC from magisk modules
• Removed everything from denylist except Google Wallet
• Set SELinux to enforcing - I set it to permissive earlier because of Viper4AndroidFX
• Reboot

Still PI checker shows red cross for MEETS_STRONG_INTEGRITY

 

[AndrzejDwo]

OK.

• Removed MHPC from magisk modules
• Removed everything from denylist except Google Wallet
• Set SELinux to enforcing - I set it to permissive earlier because of Viper4AndroidFX
• Reboot

Still PI checker shows red cross for MEETS_STRONG_INTEGRITY

that's normal and gwallet should work

 

[pndwal]

OK.

• Removed MHPC from magisk modules
• Removed everything from denylist except Google Wallet
• Set SELinux to enforcing - I set it to permissive earlier because of Viper4AndroidFX
• Reboot

Still PI checker shows red cross for MEETS_STRONG_INTEGRITY

Perfect!...

I didn't say you need strongIntegrity... When Google/banks start enforcing that it'll be a sad day for modders... Also, customers using any device w/ A7 or less + many modern OnePlus etc w/ broken keymaster will be collateral damage... deviceIntegrity is what you need ATM as stated... PW