Magisk Module Systemless Debloater
- Thread starter zgfg
- Start date
The module does not remove applications from /system_ext, although it is deleted according to the logs. For example, EmergencyInfo
Ok, you have debloated 34 apps. I hope you didn't debloat 'too many' system apos (e g , you debloated Dialer, etc) that your phone would no more work properly.
In that case you would need to filter out your DebloatList and 'install' the module again
Anyway, back to your By_3rd_HeytapIdProviderIndia:
- use root explorer and go to where Magisk keeps modules:
/data/adb/modules
- further into the SystemlessDebloater/system
- inside, create nested subfolders india/app
- go back to SystemlessDebloater/system and now into product/app subfolder
- here, you should find a subfolder By_3rd_HeytapIdProviderIndia
(inside the subfolder there should be a file: .replace)
-copy that subfolder By_3rd_HeytapIdProviderIndia (with the .replace file) from product/app to india/app
-reboot
But before doing that, check is it really neccessary. Maybe your /system/india and /system/product are mounted one to the other or so.
Please check if the By_3rd_HeytapIdProviderIndia app was already debloated (withyour previous debloating configuration you sent me in the log file)
Interesting. For me it works - my log attached.
I have debloated couple of apps from /system/system_ext/priv-app
But in my case /system_ext is mounted to /system/system_ext - see my screenshots
Please check how these two are mounted one to another on your phone (or they are not) - please send the screenshots
Edit:
Please check also in your
/data/adb/modules/Systemless Debloater/system
Does it contain nested subfolders:
system_ext/priv-app/EmergencyInfo
(inside there must be an empty file .replace)
If not, then you can create nested subfolders:
system_ext/priv-app
Then copy e.g Wellbeing folder from:
product/priv-app
to:
system_ext/priv-app
And rename the copy to have now:
system_ext/priv-app/EmergencyInfo
(with the .replace file inside)
Reboot and check if EmergencyInfo.apk is now properly debloated
If yes, go back to /data/adb/modules/Systemless Debloater/system/system_ext
and copy/rename :
priv-app/EmergencyInfo
to:
priv-app/GoogleFeedback
and to:
app/DeviceInfo
and so on
But be careful, with some of those system apps debloated, phone could stop working properly.
Also, some apps like DeviceInfo are really useful
Attachments
Last edited:
In my case, the /system_ext folder is not located correctly. It should be located in the /system folder. Why it happens?
Please read again my previous post/answer to you and:
1) Investigate if your /system_ext is mounted to /system/system_ext
This question has nothing to do with this nodule but with your ROM/system
See my screenshots, you can use Terminal app and the commands as in my screenshot.
And/or, use an appropriate file explorer - I used MiXplorer
Obaerve that here I am not talking about the structure of
/data/adb/modules/SystemlessDebloater/system_ext
and
/data/adb/modules/SystemlessDebloater/system/system_ext
but about:
/system_ext
and
/system/system_ext
2) You can try by manually copying your system_ext folder (generated by the module, with all the stuff in)
from:
/data/adb/modules/SystemlessDebloater/
to:
/data/adb/modules/SystemlessDebloater/system
I'm asking:
1) Because /system_ext should be mounted to /systen/system_ext
This is how the module assumes but from the result it seems it was not the case on your phone
In fact, module uses REPLACE mechanism provided by Magisk, and that mechanism (by Magisk documentation) works only for subfolders in the /system
Btw, are you using the latest Magisk v23?
2) Try the manual trick as above to see would it 'fix' debloating result (although I doubt if you have a strange SAR configuration on your ROM/system level as per (1))
I manually moved /system_ext to the /system folder. Now the removal has happened successfully.
Yes, im use Magisk v23
I manually moved /system_ext to the /system folder. Now the removal has happened successfully.
Yes, im use Magisk v23
Why does the patch incorrectly create a path for /system_ext?
Last edited:
Ok, so your issue is solved by manual 'intervention'. Good
Anyway, from your terminal screenshot your /system_ext is mounted to itself - which is pointless and actually wrong (should be mounted to /system/system_ext - that's the point of SAR=System As Root).
Btw, same for your /vendor and /product
Don't know what is your phone and ROM/firmware
I installed EvolutionX Android 11. The same situation with the /system_ext folder
The path should look like /systems/ system_ext
The path should look like /systems/ system_ext
Probably the custom ROM does not change SAR configuration
Nevertheless, please try the following Systemless Debloater v1.42 does it fix debloating your /system_ext apps (i.e., no more need to manually move the stuff):
<link from Mega - removed>
Please confirm if ok for you, I will upload it then for the new official module version.
Thanks
Edit: Mega link removed, this has become now the latest v1.42 release, downloadable from Github - see post #1
Last edited:
Good job. All work. What did you fix in the new version?Probably the custom ROM does not change SAR configuration
Nevertheless, please try the following Systemless Debloater version, does it fix debloating your /system_ext apps (i.e., no more need to manually move the stuff):
File on MEGA
mega.nz
Please confirm if ok for you, I will upload it then for the new official module version.
Thanks
The customize.sh script looks for every app ftom your DebloatList under /system and if not found there, additionally under /system_ext, /product, /vendor
and now added also to look under:
/india
(but you don't have /india apps)
Observe that if mounts are proper, all those paths like /system_ext, /product, /vendor will be already mounted under /system and therefore searching additionally under /system_ext, /product, /vendor is not needed
When the particular app is found, it checks if its path does not begin with "/system" and then it prepends "/system" to that path
However, that check was not good for apps found under /system_ext, it must be checked instead if the path begins with "/system/" (because the paths like "/system_ext/app/SomeApp/SomeApp.apk" already begin with "/system" but not with "/system/")
Ofc, the old search was ok for apps found under /product, /vendor
So, for the matter of fact, I have also MIUI 12.6, A11 (Mi 9T, Xiaomi eu weekly builds) but e.g. my /system_ext is mounted to /system/system_ext and hence my apps from there already begin with "/system/system_ext/..."
I realized the problem by looking into your mounts, it was strange how the script prepends /system to your /product paths but not to your /system_ext paths (for you, both /product and /system_ext are not mounted under /system hence the paths for apps found from both must be equally prepended with /system)
Edit: This version, v.1.42, uploaded now to Github as the latest release - see post #1
Last edited:
Systemless Debloater v1.43
If there are 'duplicates' on /system for an app you want to debloat (possible case with some ROMs), all 'duplicates" will be debloated now
New setting for SystemlessDebloaterList.sh, put into that file a new line:
VerboseLog="true"
to force extensive logging in the SystemlessDebloater.log file.
Comment out that line (by prepending the line with an ampersand #), for less logging (and faster module installation)
For the installation link to Github, go to OP post #1
Many thanks to @ipdev for testing on and suggestions based on his One Plus 6T with OnePlus OS where he actually does observe 'duplicates' of the /system apk files (in various folders)
For example, he has three instances of the Account.apk:
/system/india/app/Account/Account.apk
/system/product/app/Account/Account.apk
/system/product/priv-app/Account/Account.apk
All three are correctly debloated together now
If there are 'duplicates' on /system for an app you want to debloat (possible case with some ROMs), all 'duplicates" will be debloated now
New setting for SystemlessDebloaterList.sh, put into that file a new line:
VerboseLog="true"
to force extensive logging in the SystemlessDebloater.log file.
Comment out that line (by prepending the line with an ampersand #), for less logging (and faster module installation)
For the installation link to Github, go to OP post #1
Many thanks to @ipdev for testing on and suggestions based on his One Plus 6T with OnePlus OS where he actually does observe 'duplicates' of the /system apk files (in various folders)
For example, he has three instances of the Account.apk:
/system/india/app/Account/Account.apk
/system/product/app/Account/Account.apk
/system/product/priv-app/Account/Account.apk
All three are correctly debloated together now
Last edited:
If your phone is not rooted, then you're not going to install root Vanced YT but non-root, and then you don't need to 'debloat' the pre-installed newer version of YT (non-root Vanced installs as a new app, with different package name)
Otherwise, adb shell pm commands can help you for 'debloating' = disabling certain apps, but not if you need to install root Vanced YT and you first need to debloat the preinstalled newer YT
Edit: Oops, I thiught you were asking through the XDA Vanced YT thread
Last edited:
Yes But my only goal is to uninstall some default other Xiaomi apps without rooting phone. So is that possible?
Yes, possible but not in the scope for this thread. Google to learn about the commands like:
adb shell pm disable-user com.miui.analytics
adb shell pm enable com.miui.analytics
Similar threads
Top Liked Posts
-
1
Sorry man, it was all my fault, I was using the package name. I apologize for wasting your time. -
1
Sorry man, it was all my fault, I was using the package name. I apologize for wasting your time. -
20Magisk Module Systemless Debloater
Download:
GitHub - zgfg/SystemlessDebloater: Select and systemlessly debloat preinstalled system apps. Supporting up to System As Root (SAR), Dynamic partitions and Android 13. Module must be installed through Magisk app, not TWRP
Select and systemlessly debloat preinstalled...
github.com
Wiki pages by @ipdev:
with his examples of apps that can be debloated (Android, Google, Oppo, Samsung, Xiaomi, LineageOS):
*** Yet another System(less) debloater, how and why?
- Systemless means that all changes made are active only when Magisk is loaded and module is enabled.
For OTA or anything, just disable the module (or boot without Magisk) and your system partitions are no more affected
- For Android up to 9 and/or 10 (depending on devices), system partitions were read-write, hence hard-debloating by use of eg TWRP, Titanium, etc (to delete the pre-installed system apps) was possible
This is no more possible for the phones released with Android 10 and higher.
System (System As Root, Dynamical partitions) becomes read-only on the file-system level and stock apps could be debloated (the same holds for any changes on the system partitions) only by the systemless approach - by use of Magisk to dynamically overlay the required changes at boot time
Hence, this module also uses the Magisk REPLACE mechanism and dynamical mounting through the module's service.sh script
- The module debloates only (stock) apps pre-installed to the system partitions, traditionally named as /system, /system-ext, /product, /vendor and /apex; plus additionally on A12 and A13 devices, variably named system partitions like /india, /my_bigball, etc
Hence sorry, to debloat user apps installed to /data, please use the other methods (first of all, just simply uninstall them or at least uninstall their updates)
- Originally I started development with Xiaomi Mi 9T (MIUI 10-12.5, Android 10-12) and later continued with Xiaomi 11 Lite 5G NE (MIUI 12-13, Android 11-12). However, the module relies on the common Magisk overlay mechanism and the list of apps to be 'debloated' is configurable hence there are many users who successfully use this module on the various other devices (like Pixel, Samsung, One Plus, etc.), with the stock or custom ROMs, and with up to Android 13
- Original, default list coming when the module is installed will be empty - user must define then himself which apps should be debloated, depending on his device, ROM and preferences
To (re)configure the list of apps for debloating, simply edit the (textual) /Download/SystemlessDebloater.cfg config file on Internal memory.
Module automatically installs the config file with instructions inside but with the empty list
(Re)configure your list of system apps you want to debloat, reinstall the module (always through the Magisk Manager, not TWRP) and reboot - to take your changes in effect
You only need to provide the proper names (not package names) for the preinstalled system apps, the module will find their exact System paths
- However, the user bears the risks and responsibility himself (device may no more boot when certain system apps are removed/debloated) but the Troubleshooting section below provides instructions how to recover, even from the bootloop cases
Nevertheless, whenever you want to 'debloat' some service or app you are not familiar with, please google first to find what that app is really about and is it generally safe to be debloated (on your but also on the other phones and even by other methods, it doesn't matter)
Don't be afraid of the module and debloating, but be cautious what are you going to debloat
*** Installation
- Download the latest module from GitHub - scroll down, open Assets and find the latest v1.5.4 zip:
Release Systemless Debloater v1.5.4 · zgfg/SystemlessDebloater
Fix for SystemlessDebloater.cfg for Magisk v26.3
github.com
- In Magisk app (manage), open Modules tab and take Install from storage, navigate to the downloaded SystemlessDebloater.zip (as is, do not unzip)
Read what Magisk prints while installing and find the module's log in /Download/SystemlessDebloater.log file on Internal memory
To finish the installation (it applies to all Magisk modules), reboot the phone
- First time the module will not debloat anything - it will just create the input/config file /Download/SystemlessDebloater.cfg on Internal memory
Open that config file, read the instructions in the file and fill your own list of app names for debloating - look at the commented examples you will find in that config file
- Save the config file, reinstall the module and reboot.
Inspect the log and consult the Troubleshooting section below if needed
- To find what system apps you have on your phone and what are their exact names, scroll down through the SystemlessDebloater.log to the "System apps, not debloated" section
Find e.g. a line:
/system/app/Email (com.android.email)
Then copy/add just the Email name (supposed that you want to debloat the built-in Email app) into the SystemlessDebloater.cfg config file
Repeat for the other apps you want to debloat. Then reinstall the module (only on the reinstallation, module processes the config file) and reboot
Fine tune your list of apps for debloating but every time reinstall the module and reboot
- Last but not the least: Once debloated, apps can no more be found (until you reconfigure, disable or uninstall the debloater) under the Settings / Apps
Hence, if you want to delete their cache or data, do Clear cache/data before debloating the apps
Moreover, before trying to debloat any app, look first if you could simply Uninstall that app (ie, if it was a user and not the system app) from Settings / Apps
If Uninstall is not available for that app, try to Uninstall updates: updates are also installed to Data while SystemlessDebloater 'debloats' only from the System - hence the app's update on Data may still remain there
*** Troubleshooting
- What if I eg have configured the app EMail to debloat, but the app is still present?
Check if you have missed to perform Uninstall / Uninstall updates from Settings, Apps - perform, reboot and test again
Check if you have miss-spelled the application name - correct in the config file SystemlessDebloater.cfg, save, reinstall the module and reboot
App names are cases sensitive - eg, the correct name might be Email, not EMail
- To help yourself, use eg Package Manager app (from Playstore) where you can search for all the apps/services, find their exact names and installation paths (to see are them System or User apps)
- What if I change my mind and I want to un-debloat and use Email, but to debloat now eg, Chrome browser?
No problem, reconfigure the list in SystemlessDebloater.cfg, save, reinstall the module and reboot
- What if after a week or so, I realize that some functionalities on the phone were affected?
Sorry, you had decided to debloat the 'wrong' apps/services
Google about which app(s) are safe to debloat or not, reconfigure your list in the config file, reinstall the module and reboot
Or disable the module and reboot, to figure out was the problem really due to debloating
- Oops, what if I have a bootloop (phone does no more boot since the 'wrong' apps were debloated)?
If you have TWRP with the read/write access to Data, navigate to /data/adb/modules/SystemlessDebloater and by using Advanced / File explorer from TWRP, create a dummy file named disable (without extension) in that folder
Reboot and Magisk will boot but with the debloater disabled - hence, all the previously debloated apps will be un-debloated now (to see if debloating was really responsible for the bootloop)
Instead of dummy file named disable, put the remove dummy file to trigger Magisk to uninstall that module on the next reboot (all that applies to any module possibly causing your bootloops)
If the proper TWRP is not available for your device and ROM, boot to the Android Safe Mode - google for a key-combo to boot in, for my Xiaomi it takes (re)booting with Vol+ and Vol+ pressed simultaneously
Don't do anything in Android Safe mode but reboot then to 'normal' mode - Magisk will boot now with all the modules disabled (this method does not work for Magisk v20.4 or earlier)
You will have to re-enable MagiskHide/DenyList (don't worry, your list of apps to hide the Magisk from was not lost), re-enable the other modules, correct SystemlessDebloater.cfg, reinstall debloater and reboot
There is also a third method (adb wait-for-device shell magisk --remove-modules), but search yourself and read about from the Wiki Documentation on the Magisk GitHub page
*** Enough for the theory, install now and practice debloating4New version v1.5.0 is released:
Release Systemless Debloater v1.5.0 · zgfg/SystemlessDebloater
Automatically search through packages to find...
github.com
With Android 13 there are now ROMs where the additional system partitions are variably named like /india, /my_bigball, etc - the module now automatically finds and includes those names into the list of partitions to be scanned for debloating
Also, debloating from /apex is now supported - but be careful, services pre-installed to that partition are usually essential for the proper booting and functioning of your device
Of course, the module is still only for debloating the System apps, for user apps on /data partition use the other methods (simply uninstall the unwanted user apps or disable them by pm disable command, etc) - see also the OP instructions4Thanks a lot to @ipdev for discussing and sharing ideas, encouraging and for successful testing on Xiaomi Poco F2 (debloater found most of the same MIUI apps as above) and OnePlus 5T
Also, thanks for your successful test on Pixel 3aXL with Android 11:
Works on Pixel 3aXL. (Stock Android 11. Magisk canary.)
Attached the SystemlessDebloater.log from 3aXL.
And the SystemlessDebloaterList.sh I use for testing. (remove the .txt)4Hello again
Pretty much figured out the above, got some 160 odd apps leftover with everything seemingly still working. The last bit I found is that removing EuiccService breaks Background usage limits app selection within Battery and Device Care.. Hope it helps someone. Btw - I do use System App Remover ROOT (for now) to remove whatever apps it can remove, e.g. not Apex. Might update .sh below at some point again.
[ *** = temp disabled FYI | ymmv ]
Found another (unrelated) issue in the meantime on my Samsung Android 13 journey, here: https://xdaforums.com/t/magisk-module-universal-safetynet-fix-2-4-0.4217823/post-88010513
[ Fwiw, I could either give up on restricting Google Play Services but knowing that it does request e.g. cam and mic access annoys the .sh out of me. Or I could go and use something like AndroidFaker and AppOps but it's just not the same (yet) as XPrivacyLUA. At that rate, might as well buy an iPhone soon.. :/ ]4I spent a lot of time trying to figure out why I got random Android WebView crashes when debloating. Everything seemed to be working just fine (I been debloating for years and got my special list) so wasn't sure what was happening.
Long story short - various apps crashing happens only when uninstalling "UwbApplication" aka "com.samsung.android.uwb". Which is odd enough.
More odd is that the crashing can temporarily be stopped by clearing the cache of Google Play Services ...
Either someone did some pretty bad coding or there are some dependencies that probably should not exist, go figure.
Be happy to share my final list once I am eventually happy with the result which will take some time ;]
