[Magisk] zgfg:
Some observations about Magisk overlay/mounting

1) For debloating my MIUI I use my Magisk module. It contains a system folder with the subfolder tree extending to 50 stock apk files, to overlay them with the empty apk files.

E.g.: system/product/priv-app/Wellbeing/Wellbeing.apk

Given module is attached as debloat-1.zip

I use it for over two months, never had any problem with:

- Phone boots stable, SafetyNet is ok (if needed, I fake ro.product.model but that's another, well known story)

- All unwanted stock applications (from /system/*app/, /system/product/*app/, /system/vendor/*app/) can be seen by MiXPlorer as replaced with the empty apk files.

System/Applications does not find any of those apps and they are also not present on the Home screen or Drawer.

Looking by e.g. Package Manager, none of the apps can be found either by app or package names, neider by: adb shell pm list packages

So far, so good. Here and there I extend the system folder with a new candidate for debloating, and carefully test if everything still works fine.

Anyway, the phone is my daily driver and I don't have problems (crashes, freezing, functionalities not working, whatever)

2) If it aint broke, don't fix it - but I got bored that every time I have to find and extend my system tree with the exact path for every new wanna-be debloated app (frankly, I just got bored and wanted to experiment more).

Hence I wanted to have a script that would go through a for loop (with the list of unwanted app names), and inside the loop search for their paths in system subfolders as mentioned above, and mount a dummy (zero bytes long) file over the each particular apk

Made it, tested the script in Terminal, printed all paths and compared them with my paths in the system tree from (1) - all was ok.

Removed the system from module (1) and put the script as service.sh instead - attached as debloat-2.zip module

Phone worked stable and debloating worked as described under (1).

Until, a day later I found that Basic Integrity was broken - I thought first what the hack G is doing again, but then switched back to module (1) and SafetyNet was passing as usual

I tried then even by renaming service.sh to post-fs-data.sh (run by Magisk much earlier than service.sh - consult the Magisk Docs), but it didnt help: Debloating still ok, but Basic Integrity failing again

3) Eventually I renamed it back to service.sh and tried by putting a while loop to wait at the beginning of the script for booting to complete - found it in the scripts from [MENTION=7280276]ipdev[/MENTION].

It didnt help, to the contary - phone was crashing now already when I was typing my pins for SIM cards and screen unlock

I reduced the loop in the script to list only a few apps (and no services) and the phone booted well but showing icons for 'debloated' apps on the Home screen (clicking does not start those apps).

Even funnier, System/Applications was showing debloated apps but by package names, not by their app names - IMO, similarly was observed and reported by [MENTION=3335621]dr4go[/MENTION] in the Vanced thread (about overlaying the YouTube app)

All together, waiting for boot to complete was not the way to go

---

Hence I'm wondering why (2) works differently than (1) - debloating in both cases is ok, but (2) breaks Basic Integrity.

IMO, (2) somehow overlays the given apks either earlier or later than (1), causing somehow (due to debloating a certain critical service) to break the Integrity.

Again, there are exact the same stock apks debloated by (1) or (2)

I cant believe that (2), due to executing a shell script and searching for each of the fifty apps throught the various folders executes too slow comapred to (1), where the system tree to be overlayed is 'hard coded'

Who wants to experiment: modules are attached, just unzip and copy the folder(s) under /data/adb/modules

Use debloat-1 xor debloat-2 (never both).

For debloat-1, one must adapt the system tree with his/her apk paths for debloating, for debloat-2 one must only adapt the app names in the for loop

Edit: Re-uploaded debloat zip files that are flashable from Magisk Manager

If it won't boot, use TWRP (assuming you have it) to simply rename e.g. service.sh to service.bak to disable debloat-2 overlay

PS: Stock apps to be debloated nust be first applied with Uninstall updates to the app, from Settings/Apps - otherwise their active versions are no more stock apks in /system but their updates installed to /data

Edit: There was a problem with uploading/downloading the zips.

Links to download from Mega are given in the new post:

https://xdaforums.com/showpost.php?p=83709627&postcount=42110

Resolution:

Found the culprit - stock apps from /system/priv-app must not be mounted to - for them it causes Basic Integrity to fail.

I can safely debloat them only by debloat-1 approach, by directly overlaying a system/priv-app tree with the dummy apk files

For the other stock apps from all the other folders from /system, /product and /vendor (40 apps, all apps there I needed for my debloating) I can use debloat-2 script approach to mount a dummy file to their apk files, without breaking the Basic Integrity/SafetyNet

See:

https://xdaforums.com/showpost.php?p=83710645&postcount=42119