[Magisk] zgfg:
Title: Magisk Module Installer - REPLACE mechanism

Couple of comments here

1) I had a follow--up post with s clear description of my thoroughfurther tests, resulting that for me, ONLY mounting to /system/priv-app breaks Basic Integrity.

Mounting to /system/app, /system/data-app, three /system/product/*app folders and three /system/vendor/*app folders DOES NOT break Basic Integrity (therefore, does not break SafetyNet). [MENTION=7280276]ipdev[/MENTION] tested and confirmed the same for another Xiiaomi (on non-MIUI phones, it might be different but would be worth to test before generalizing that any mounting to /system breaks BI)

Besides (related to your post in Vamced thread), my stock YouTube is in /system/product/priv-app and therefore it can be safely debloated by mounting a dunmy file (since it is not in /system/priv-app)

2) Even for stock apps on /system/priv-app, you can make (it was there in my hybrid module for my 11 apps from /system/priv-app) local system folder with a tree going down to the paths corresponding to the apps for debloating, then Magisk merges those paths to /system WITHOUT using MOUNT, and that way it does not break BI/SN!

So, before drawing a No way conclusion, you could have tested:

- Where is your e.g. stock YouTube app

- If not in /system/priv-app, whether mounting mechanism on your phone does also not break BI/SN

- If in /system/priv-app, and/or if mounting breaks your BI, then using that local system folder mechanism, letting Magisk to merge it without mounting, how about your BI then?

Btw, when I was testing, I booted more than 20 times (testing first in various combinations and finaly one by one for all my 11 /system/priv-app stock apps) with broken BI - and nothing terrible happenned. Later I booted without mounting to /system/priv-app, passing again SN and I didn't have any consequences due to previous testing with broken BI

But as you pointed out:

If you only wanted to debloat stock YT due to Vanced (to have it surviving reboot), there is really no reason for. One must only assure that there are no multiple YT folders in /data/app (uninstall user updates of YT, clean remaining YT folders from /data/app if any) - that will fix Vanced to survive reboot

---

Nevertheless, I've been playing more in the meantime, here comes a new debloater (I didn't want to bother about, but you pulled my leg now?):

https://mega.nz/file/k48knRAC#SFDIcYRNKKiVgzsXdzkj2OsAdUuIwKlZMidEbRB8nSw

It's interesting not just about the debloater itself but also about the Magisk Module Installer mechanism (REPLACE var) the module uses, and IMO good to see how that mechanism works

This debloater module has no more service.sh (neither post-fs-data.sh) script.

It has only the customize.sh script that executes only once, at the time of module installation or reinstallation/update

The script goes through the for loop with a list of unwanted stock app names.

List is sourced from /Download/debloat-list.sh from Internal memory (if file does not exist, module will create the file with an example for the list).

Edit your list of unwanted apps to DebloatList var in debloat-list.sh and (re)install the module (always from Magisk Manager, not from TWRP)

The for loop finds the /system/* paths for unwanted apps and lists all their paths to the REPLACE var..Magisk Module Installer will then go through REPLACE var to create a local system folder with paths for all apps listed for debloating, and with a dummy .replace file 'replacing' (not precisely said but to make it 'simpler' at the moment) each application's apk file

Magisk docs precisely describe the REPLACE var and .replace files mechanism (please read there), but the important point is that Magisk then performs the overlay itself (each time on rebooting), hence we DON'T USE MOUNT and thus the stock apps are debloated without breaking the Basic Integrity/SafetyNet.

Debloating is useful for stock firmwares coming with all kinds of bloatware, althoung maybe not needed for the YT/Vanced purpose