Hi everyone,
I am using the application Raiffeisen Twint (version 1.2.16.0, https://play.google.com/store/apps/details?id=ch.raiffeisen.twint) on my Magisk's rooted Google Pixel (Android 8.0, Nov. 2017) without problems for a while, but since Magisk 14 versions, the application stopped working and the application reports that root is detected.
I have successfully updated to Magisk 14.5 (from 14.2), but root is still detected by the application, even with Magisk Hide activated for the application and the Magisk Manager package moved to a random name (could also be related to the updated application).
I have cleared the data of the application several times and it doesn't help and root is still detected by the application...
Anyone has a idea?
Thanks for your answers!
Like I said in the Magisk support thread, I can hide Magisk from that app just fine (on Magisk v14.5 beta)...
You don't happen to have any other mods that might trigger an app looking for root (like Xposed)? Can your device pass SafetyNet? Have you previously been rooted with any other root method and do you have any remnants of that left (root management apps, etc)? Do you have any apps that are known to be used for questionable purposes. By "questionable purposes" I mean getting access to paid features without paying, etc. Not necessarily that you use the app for this, but that the app might be used in such a manner... Etc, etc, etc. Every little detail might count.
Hi Didgeridoohan,
Thanks for helping me!
I do not have any mods installed in Magisk and also no Xposed. My device is passing SafetyNet!
I have performed a factory reset last week and since that I only rooted my device with Magisk 14.2, so no other rooting applications used. For details, I have unlocked bootloader, TWRP recovery installed and developer options and USB debugging activated.
My settings in Magisk are:
I have following applications installed on my device:
https://pastebin.com/pmt4jBMV
Do you see any applications with "questionable purpose"?
I get this message in the application:
Thanks a lot!
At a quick glance everything looks ok...
I did some experimenting with the other Raiffeisen apps you have installed, in case they also detect root and "tell" on you. At least one of them did detect root, but from what I could see it didn't make any difference for Twint.
I also tested installing a few of the root apps you had installed (in case the app looks for certain known apps), but that didn't make any difference either. I could still successfully hide root.
My guess is that it's something along these lines tough. That it's using another app or detecting a root app. You could start experimenting with that. Clearing data for the other Raiffeisen apps and adding them to MagiskHide and also removing root apps. Try disabling USB debugging and developer options as well (didn't make difference for me, but worth a shot).
Simple. Change name of package from settings in Magisk Manager, then MAKE SURE you add twint app to magisk hide list, then ERASE DATA of twint app, change package name once again and run twint. Working with Magisk 14.5. Screens if u want available. Or video.
Hi Didgeridoohan, Hi Mamama07,
Thanks for your help, but sadly none of your suggestions did worked... until the update of the application released yesterday, to fix problem related to rooted devices! [emoji3]
Thanks anyway again for your help! [emoji106]
I had the same problem (with BCV Twint) and after a few tries, changing Magisk Package Name worked!
Magisk 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 system apps. Supporting up to System As Root (SAR), Dynamic partitions and Android 13. Module must be installed through Magisk app, not TWRP - GitHub - ...
github.com
GitHub - Magisk-Modules-Alt-Repo/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 system apps. Supporting up to System As Root (SAR), Dynamic partitions and Android 13. Module must be installed through Magisk app, not TWRP - GitHub - ...
github.com
Wiki pages by @ipdev:
ConfigScript
Guide for the Systemless Debloater Module. Contribute to mModule/guide_sDebloater development by creating an account on GitHub.
github.com
with his examples of apps that can be debloated (Android, Google, Oppo, Samsung, Xiaomi, LineageOS):
CommunityList
Guide for the Systemless Debloater Module. Contribute to mModule/guide_sDebloater development by creating an account on GitHub.
github.com
*** 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.3 zip:
https://github.com/zgfg/SystemlessDebloater/releases/tag/153
- 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 debloating
IMPORTANT
Since the version v1.5.1, SystemlessDebloater module supports a new SystemlessDebloater.cfg config file - thanks to @ipdev
Update will create the new config file and transfer your DebloatList
Please delete then your old SystemlessDebloaterList.sh input file and read and use the new config file instead
---
For more info about the SystemlessDebloater.cfg config file, please see: Wiki pages from @ipdev:
ConfigScript
Guide for the Systemless Debloater Module. Contribute to mModule/guide_sDebloater development by creating an account on GitHub.
github.com
and his examples what apps can be debloated (Android, Google, Oppo, Samsung, Xiaomi, LineageOS):
CommunityList
Guide for the Systemless Debloater Module. Contribute to mModule/guide_sDebloater development by creating an account on GitHub.
github.com
On my Xiaomi Mi 9T, eea Stable QFJEUXM 12.0.2 I safely debloat the following apps:
Code:
DebloatList="
AnalyticsCore
AntHalService
BasicDreams
BookmarkProvider
CatchLog
Chrome
CneApp
EasterEgg
facebook-appmanager
facebook-installer
facebook-services
FileExplorer_old
GlobalFashiongallery
GlobalMinusScreen
Gmail2
GoogleFeedback
GooglePartnerSetup
HybridAccessory
HybridPlatform
IdMipay
InMipay
Joyose
MiBrowserGlobal
MiBrowserGlobalVendor
MiCreditInStub
MiDrop
MiLinkService2
MiPicks
MiPlayClient
MiRcs
MiRecycle
MiService
MiuiBrowserGlobal
MiuiBugReport
MiuiDaemon
MSA-Global
Netflix_activation
Notes
PartnerBookmarksProvider
PaymentService
PhotoTable
Stk
TouchAssistant
Traceur
Turbo
uceShimService
Velvet
VsimCore
wps_lite
YellowPage
Zman"
E.g., I debloat YouTube and install Vanced YT root.
Similarly, I debloat GMail, Wellbeing, Netflix, Facebook, Turbo, etc - inspect and exclude from the list those apps you want to keep
Also, DebloatList I used for Mi 9T but Xiaomi.eu weekly 20.9.17 (MIUI 12, Android 10):
Code:
DebloatList="
AndroidAutoStub
AntHalService
BookmarkProvider
Browser
BTProductionLineTool
Calculator
CatchLog
CneApp
EasterEgg
Email
GoogleFeedback
GooglePartnerSetup
Health
Joyose
Lens
MiMover
MiPlayClient
MiRecycle
MiService
MiuiBugReport
MiuiDaemon
Notes
PaymentService
Stk
TouchAssistant
Traceur
uceShimService
Velvet
VsimCore
WebViewGoogle
wps_lite"
and for Xiaomi.eu Stable 12.0.6:
Code:
DebloatList="
AndroidAutoStub
AntHalService
BookmarkProvider
Browser
BTProductionLineTool
Calculator
CatchLog
CneApp
EasterEgg
Email
GoogleFeedback
GooglePartnerSetup
Health
Joyose
Lens
MiMover
MiPlayClient
MiRecycle
MiService
MiuiBugReport
MiuiDaemon
Notes
PaymentService
Stk
TouchAssistant
Traceur
uceShimService
Velvet
VsimCore
WebViewGoogle
wps-lite"
You may exclude e.g., Calculator,Email, Health or Lens, if you want to use them.
You can expect most of these apps also on the other MIUI firmwares. Installation folders on System may vary, but module will find their paths
EDIT:
SystemDebloaterList.sh and DebloatList were used in the module versions v1.5.0 and earlier, since v1.5.1 the module uses SystemDebloater.cfg
Thanks 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:
ipdev said:
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)
Click to expand...
Click to collapse
Reserved
Over the weekend when I have time to fix any potential bricking or boot loops, I'm going to try this on my A/B device (One Plus 7Pro, GM1917, OOS 10.3.5) ... unless before then anyone indicates that this is not even likely to work on my phone.
If I end up doing this, I'll report my results.
.
HippoMan said:
Over the weekend when I have time to fix any potential bricking or boot loops, I'm going to try this on my A/B device (One Plus 7Pro, GM1917, OOS 10.3.5) ... unless before then anyone indicates that this is not even likely to work on my phone.
If I end up doing this, I'll report my results.
.
Click to expand...
Click to collapse
It does not matter if it system-as-root or a slot device.
By time modules are run, system paths are set.
The active slot partition is running, and (if needed) switch root has happened.
Root directory is set to / and system directory is set to /system
curious about OxygenOS, do not run it very much so I am not sure what should/could be removed.
Cheers.
PS.
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)
Quick edit.
Since the back-side move for xda is still going, there are some errors while in transition.
Since attachment is not working at the moment. GoogleDrive - Link
ipdev said:
It does not matter if it system-as-root or a slot device.
By time modules are run, system paths are set.
The active slot partition is running, and (if needed) switch root has happened.
Root directory is set to / and system directory is set to /system
curious about OxygenOS, do not run it very much so I am not sure what should/could be removed.
Cheers.
PS.
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)
Click to expand...
Click to collapse
OxygenOS isn't as bad, bloat-wise, as some other OS's, such as what comes with Samsung. But there are still things that I don't want, such as the OnePlus camera and a few other items.
I'll report back here after I try this.
.
ipdev said:
It does not matter if it system-as-root or a slot device.
By time modules are run, system paths are set.
The active slot partition is running, and (if needed) switch root has happened.
Root directory is set to / and system directory is set to /system
curious about OxygenOS, do not run it very much so I am not sure what should/could be removed.
Cheers.
PS.
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)
Click to expand...
Click to collapse
Thank you for testing on A11.
Log cannot be downloaded, 404?
zgfg said:
Thank you for testing on A11.
Log cannot be downloaded, 404?
Click to expand...
Click to collapse
Looks like some more hiccups on xda back-side again.
Will be nice once the transition is complete, xda will be fast and stable again. :fingers-crossed:
Updated my prior post with a gDrive Link.
If you look at the log, you will notice chrome is not debloated.
The stub is debloated, Chrome (Think it is in product/app) is a gzip version of the Chrome apk.
Chrome is automatically installed into /data/app/HashStringOrSomething/com.android.chrome-HashStringOrSomething/Chome.apk
I have not taken time to look into that change.
Cheers.
ipdev said:
Looks like some more hiccups on xda back-side again.
Will be nice once the transition is complete, xda will be fast and stable again. :fingers-crossed:
Updated my prior post with a gDrive Link.
If you look at the log, you will notice chrome is not debloated.
The stub is debloated, Chrome (Think it is in product/app) is a gzip version of the Chrome apk.
Chrome is automatically installed into /data/app/HashStringOrSomething/com.android.chrome-HashStringOrSomething/Chome.apk
I have not taken time to look into that change.
Cheers.
Click to expand...
Click to collapse
Interesting - what happens when you debloat Chrome-Stub from Product and leave Chrome on Data, does it still run?
Btw, I do use Chrome (because of the integrated translator, making me easy to sometimes read worldwide forums if needed) and I didn't want to debloat originally. However, my preinstalled version on Product was not the latest, and Google Play was offering me to update, but updating Chrome was always failing.
I downloaded the apk from ApkMirror but installation had also failed
Then I debloated (at that time, prior to this debloater I used to manually create my system folder given to Magisk to overlay, and with dummy apk instead of with .replace file) and only then I was able to install Chrome apk (ofc to Data) and since then, to regularly update it through Playstore
One more thing. I've found some people claiming that Chrome breaks to run if Playstore shows Device is not certified.
But back in the spring when Google started to play with enforcing CTS Profile Hardware attest, and prior than @Displax invented ro.product.model spoofing (to force Basic attest and to pass CTS/SafetyNet, to get Device certified), my CTS was failing and Device was not Certified but I had no problems using Chrome on daily basis
---
Also, you have PrebuiltGmail and Music2, I had Gmail2 and FileExplorer_old (I had to use Package Manager to find that Gmail was installed as Gmail2/Gmail2.apk and similarly the Android FileExplore as FileExplorer_old.apk)
Btw all Mi* and Miui* stuff apply only for debloating Xiaomi
In your input list you have lite and wps (both are not found in the log), mine was wps_lite (WPS preinstalled to Vendor) - please check
zgfg said:
Interesting - what happens when you debloat Chrome-Stub from Product and leave Chrome on Data, does it still run?
Btw, I do use Chrome (because of the integrated translator, making me easy to sometimes read worldwide forums if needed) and I didn't want to debloat originally. However, my preinstalled version on Product was not the latest, and Google Play was offering me to update, but updating Chrome was always failing.
I downloaded the apk from ApkMirror but installation had also failed
Then I debloated (at that time, prior to this debloater I used to manually create my system folder given to Magisk to overlay, and with dummy apk instead of with .replace file) and only then I was able to install Chrome apk (ofc to Data) and since then, to regularly update it through Playstore
One more thing. I've found some people claiming that Chrome breaks to run if Playstore shows Device is not certified.
But back in the spring when Google started to play with enforcing CTS Profile Hardware attest, and prior than @Displax invented ro.product.model spoofing (to force Basic attest and to pass CTS/SafetyNet, to get Device certified), my CTS was failing and Device was not Certified but I had no problems using Chrome on daily basis.
Click to expand...
Click to collapse
PlayStore issues are weird at best.
Hit or miss, depends on the device and/or setup.
Certificataion does not seem to play a big part over all.
If it does then Google's has more issues than fixing SafetyNet to worry about.
Sometimes it is just a Google being Google.
I will look into Chrome tomorrow.
I normally use Chrome Dev PlayStore - Link.
More so now, Brave Browser PlayStore - Link.
zgfg said:
Also, you have PrebuiltGmail and Music2, I had Gmail2 and FileExplorer_old (I had to use Package Manager to find that Gmail was installed as Gmail2/Gmail2.apk and similarly the Android FileExplore as FileExplorer_old.apk)
Btw all Mi* and Miui* stuff apply only for debloating Xiaomi
In your input list you have lite and wps (both are not found in the log), mine was wps_lite (WPS preinstalled to Vendor) - please check
Click to expand...
Click to collapse
No harm checking for apps that do not exist on the device.
It may cause extra lines in the log file and one or two seconds of install time.
My bad.
Must have split wps_lite when I was adjusting the list. Then when sorting, it just put lite and wps in the correct order.
---
I re-flashed and/or reverted a few phones tonight and added them to the gDrive Link.
The files listed as _pfile.list (preinstalle files) are a list of files located in app and/or priv-app of system, product and vendor.
I use a shell scripts for this kind of stuff, [ because I am lazy ] primarily with adb shell.
I adjusted the one I use to make the pfile list.
list_pfiles.sh - Still needs to be run as root.
list_pfiles.sh needs to be located in a writable directory. (sdcard/Download | data/local/tmp | ...)
It still uses a static NAME= variable that you will want to change.
I added a few things to make it run from a root file manager like fx or mix.
With the addition (work from a file manager app/or called from a diferent directory), if you rename the script file, you will also have to adjust the SCRIPT= variable to match.
Cheers.
Edit:
2021.Aug.21
I updated the list_pfiles script.
To Use:
Copy this script to the device.
Recommended to use the /sdcard/Download/ directory.
Run from adb shell (or a terminal app) using the sh command.
sh list_pfiles.sh
Run from a file manager that is able to execute a script file.
Note: May or may not work depending on file manager..
ipdev said:
PlayStore issues are weird at best.
Hit or miss, depends on the device and/or setup.
Certificataion does not seem to play a big part over all.
If it does then Google's has more issues than fixing SafetyNet to worry about.
Sometimes it is just a Google being Google.
I will look into Chrome tomorrow.
I normally use Chrome Dev PlayStore - Link.
More so now, Brave Browser PlayStore - Link.
No harm checking for apps that do not exist on the device.
It may cause extra lines in the log file and one or two seconds of install time.
My bad.
Must have split wps_lite when I was adjusting the list. Then when sorting, it just put lite and wps in the correct order.
---
I re-flashed and/or reverted a few phones tonight and added them to the gDrive Link.
The files listed as _pfile.list (preinstalle files) are a list of files located in app and/or priv-app of system, product and vendor.
I use a shell scripts for this kind of stuff, [ because I am lazy ] primarily with adb shell.
I adjusted the one I use to make the pfile list.
list_pfiles.sh - Still needs to be run as root.
list_pfiles.sh needs to be located in a writable directory. (sdcard/Download | data/local/tmp | ...)
It still uses a static NAME= variable that you will want to change.
I added a few things to make it run from a root file manager like fx or mix.
With the addition (work from a file manager app/or called from a diferent directory), if you rename the script file, you will also have to adjust the SCRIPT= variable to match.
Cheers.
Click to expand...
Click to collapse
Pixel comes with only G stuff but interestingly, without Wellbeing
Velvet.apk, what is the package name (you should still be able to find the name on /data/data)?
When you have Velvet (Poco F1, F2 and One+ 5T), do they also have Google.apk = com.google.android.googlequicksearchbox?
Btw, if you use MiXPlorer and choose Tools, App Remnants, you can see /data/data folders for debloated apps (and you can remove them)
HippoMan said:
Over the weekend when I have time to fix any potential bricking or boot loops, I'm going to try this on my A/B device (One Plus 7Pro, GM1917, OOS 10.3.5) ... unless before then anyone indicates that this is not even likely to work on my phone.
If I end up doing this, I'll report my results.
Click to expand...
Click to collapse
I did it just now, and it worked wth no problems on my device! For my initial test, I used SystemlessDebloater to remove GooglePartnerSetup, and it was indeed removed. No bootloops, no problems.
Good work on this module!
zgfg said:
...
Btw, if you use MiXPlorer and choose Tools, App Remnants, you can see /data/data folders for debloated apps (and you can remove them)
Click to expand...
Click to collapse
Well, in my case, GooglePartnerSetup doesn't appear anywhere among MiXPlorer's "App Remnants", even though other /data/data items are indeed being displayed there. But this is not causing any kind of issue on my device, so I am not concerned.
.
zgfg said:
Pixel comes with only G stuff but interestingly, without Wellbeing
Click to expand...
Click to collapse
Don't worry, Google would not forget to bundle it.
Digital wellbeing is named WellbeingPrebuilt.
package: name='com.google.android.apps.wellbeing'
I just did not add it to the debloat list.
zgfg said:
Velvet.apk, what is the package name (you should still be able to find the name on /data/data)?
When you have Velvet (Poco F1, F2 and One+ 5T), do they also have Google.apk = com.google.android.googlequicksearchbox?
Click to expand...
Click to collapse
Velvet is Google.
package: name='com.google.android.googlequicksearchbox'
As far as I know, Velvet is the bundled and/or GApps name used.
Cheers.
HippoMan said:
I did it just now, and it worked wth no problems on my device! For my initial test, I used SystemlessDebloater to remove GooglePartnerSetup, and it was indeed removed. No bootloops, no problems..
Click to expand...
Click to collapse
Just a short question - you have A11 on your OnePlus 7Pro?
zgfg said:
Just a short question - you have A11 on your OnePlus 7Pro?
Click to expand...
Click to collapse
One Plus 7Pro, GM1917, OOS 10.3.5 ... as I mentioned above OOS 10.x is A10.
.
zgfg said:
Interesting - what happens when you debloat Chrome-Stub from Product and leave Chrome on Data, does it still run?
Btw, I do use Chrome (because of the integrated translator, making me easy to sometimes read worldwide forums if needed) and I didn't want to debloat originally. However, my preinstalled version on Product was not the latest, and Google Play was offering me to update, but updating Chrome was always failing.
I downloaded the apk from ApkMirror but installation had also failed
Then I debloated (at that time, prior to this debloater I used to manually create my system folder given to Magisk to overlay, and with dummy apk instead of with .replace file) and only then I was able to install Chrome apk (ofc to Data) and since then, to regularly update it through Playstore
Click to expand...
Click to collapse
Still have to test some more.
So far only on my Pixel aOS 11.
This is a little tricky to explain my testing/findings.
- Long post, truncated it for now. -
Not logged into Google. (PlayStore)
With Chrome stub active, Chrome is treated as a system app.
Even though the full version is in data it can not be uninstalled only disabled.
PlayStore shows an available update for Chrome.
If stub is removed (debloated), Chrome is treated as a user app.
You have the option to uninstall.
PlayStore does NOT show an update for Chrome.
Did not matter if I cleared cache and/or data on PlayStore or re-scan with with PlayProtect.
This is odd, since Google should still want to update even if it is just a user app.
I'll have to dig though the user agreement again.
Might be automatic update only when Google apps are included (system app) when not logged in.
--
As soon as I logged in, Google immediately updated some back-end.
Chrome is now available for an update and it updated fine.
This is also where some oddities came in.
--
<TRUNCATE>
--
Still have to double check everything.
Seems to be an issue distinguishing between system and user apps.
Should have time this weekend to redo and verify every step I used for testing.
As of now, I would suggest the same as you did it.
Debloat Chrome (stub)
Uninstall Chrome (should be considered a user app after the debloate.)
Install from another source (if need be then update from PlayStore.) or just install from PlayStore.
Cheers.
Btw, released v1.3.5 through the OP post #1 - just to log to the logfile the Android version, is it SAR and is it A/B - would be nice if you can test does it log correctly when you have time and A/B device.
Unfortunately, still unable to resolve a miss-communication with the bot to successfully submit to Repo
Can somebody dhare his debloat app list? Or the best, .sh file? İt would be great