[Magisk] pndwal:
I think never!...

... Saw @chiteroman say that recently too, but I/others think it was a mistake... I know of no benefit... (Edit; my mistake.... He didn't say it...)

I had root hidden from that for a long time ant though it was necessary... I believe it used to be... Recently I removed hiding as @zgfg mentioned it wasn't needed and it hasn't complained... Doesn't hurt however... And it's the only Google app you should consider hiding AFAIK...

Still, seems we can say there's no need to hide anything Google ATM... 😛 Nb. Hiding root from some Google apps breaks stuff, like Webview...

... Well we always needed to hide root from Droidguard/attestation process (previously loosely called SafetyNet process), ie Play Services com.google.android.gms.unstable, but MagiskHide used to add that automatically to HideList on toggling on... Next, John added the main process, com.google.android.gms for devices where Magisk no longer resided in /sbin, basically devices with Android 11+... Since major refactoring (randomseed no longer used for Magisk tmpfs mount path) modern devices continue to require root hidden from both GMS processes.

Then, with Magisk 24+ ("The Age of Zygisk"), people began moving from @kdrag0n's Riru based to Zygisk based USNF (he'd published this 2 months earlier that for early 23010+ Canary with experimental Zygisk users) which was the first iteration to integrate its own root hiding since the use of Denylist hiding for GMS would break USNF's main functions (injecting fake keystore in GMS to trigger fallback to basic attestation on device and using prop spoofs targeting Droidguard/attestation process to bypass several server end prop based hardware evaluationType verdict enforcements) since DenyList reverts/denies Magisk module modifications in processes and Shamiko or other proper hiding solutions that, like MagiskHide hide/unmount without denying/reverting Magisk modifications, were not yet available... Also, because DenyList use breaks the fix, Zygisk based USNF removed GMS processes from denylist on reboot if they were added... A later commit from @ipdev allowed these processes to remain if Denylist is not enforced. Nb. Shamiko hiding can be used in this case and doesn't break USNF as it doesn't actually use DenyList (the Magisk function/module); it simply hijacks the list for convenience but uses it in HideList mode.

So users in general still didn't need to add the processes manually...

However, if using an old (A7 and earlier launch version, pre Keymaster 3) device without USNF (it could be used for basic root hiding on Android 7 devices) or custom ROMs that integrate their own spoofing with Magisk, manually adding Droidguard/attestation or both GMS processes ourselves is required since MagiskHide was sunsetted... Such devices can still pass this way at least with an simple solution like MHPC to set "MagiskHide sensitive props" (ie suspicious props MagiskHide used to rectify) to non-suspicious values...

Nb. Riru based USNF never got inbuilt root hiding from @kdrag0n so these builds were only for users sticking with Magisk 23.0... Even when proper root hiding was available with Shamiko, Riru users were still out of luck since Shamiko uses Zygisk hooking which is incompatible with Riru's...

So you don't need ANY of them while using PIF AFAIK... BTW I believe GSM is Global System for Mobile Communications... GMS is Google Mobile/Services aka Google Play Services...

As above...

🤔 Why, have you added GMS?... It's not clear...

Anyway, as explained you STILL don't need it in denylist... I saw the @chiteroman comment about adding it with Shamiko use too

but I'm pretty sure he's mistaken...

I'm using Shamiko and DenyList disabled w/o added the processes in hijacked list (and I'm sure others are too) and root is NOT detected by Droidguard VM or GMS up the line or DEVICE_INTEGRITY would fail...

Nothing Google... Nothings changed in that respect...

We just can't use the same fingerprint props to achieve the required mismatch for bypassing server end hardware-backed verdict enforcement so a working one was implemented and various other prop changes etc...

I think you just need to read the context... It's pretty clear...

No, and Yes (we don't)...

Ka-ching!

Ya... Context is everything...

Per comment above...

Per comments above, they were added automatically each time you toggled MagiskHide...

Welcome! 🙂 PW