The "unremovable" part is inaccurate. While you can't completely remove it because it resides on the system partition, you most probably can still disable it with an adb command:
adb shell pm uninstall --user 0 com.package.name
This command is very powerful as it works for any app, even those that have "disable" greyed out in the settings. I disabled the Galaxy Store on my S9 this way for example.
To be pedantic, yes, but not in a way that matters. The system partition is read-only. Mounting it read-write would require root and any modifications would break system updates. The apk will still be physically present in the file system, however, none of its code will run and it will be removed from your launcher and installed app list in settings, which IMO still counts as a removal.
Also, English is not my native language. I feel like I did get my point across anyway.
The system partition is made some fixed size, the same way disk partitioning works on PCs, and never resized, because resizing file systems is still a non-trivial task. It often has some free space too to accommodate future system updates.
On my 128 GB Pixel 9 Pro, /data is 109 GB. The rest is /system (although `df -h` doesn't show it explicitly, no idea what's up with that) and various other system-related partitions.
Regardless of the point, this language is extremely unhelpful here, especially considering op tried with good intent to help people dealing with the issue.
And there are other analogies too, e.g with certain diseases being "functionally cured" vs "cured." Did the GP use the wrong word? Sure. But making that the sole focus of criticism misses the intent of the GP and the greater value of the whole comment, which instructs people on how to disable it so that it's functionally non-impactful.
I had a Samsung phone and did the same with mine. Wrote a small tutorial here(https://harigovind.org/notes/removing-samsung-android-bloatw...). But even then, these apps will pop right back after system updates and those were becoming more frequent. I got rid of it shortly after, nowadays I use Moto where bloatwares are comparatively minimal.
This does not work on all phones. Some OEMs (like Motorola) leverage the 'nodisable' feature to prevent this and other APKs from being disabled.
On my 2025 Motorola RAZR 5G, in /product/etc/nondisable are a series of XML files listing carrier and activation apps for Dish Wireless, Tracfone/Verizon Value, T-Mobile, the Amazon App Manager, and two apps provided for finance providers PayJoy (who lock and disable phones for financial product recovery) and one for Claro internally (that operates similar to Payjoy).
These affect the "disable" button and the "pm disable" command, I believe. The "uninstall" command can't be prevented from working to my knowledge.
But then I haven't had any experience with carrier phones. We just don't do that where I live, all phones are sold unlocked for full price and all plans are prepaid.
Words don't just have a literal, technical meaning. If the phone itself doesn't allow a straightforward, user friendly happy-path for removal, it might as well be "unremovable" in a sense that it is indeed unremovable for most users. "adb shell etc" implies that one has a PC with this tool correctly installed, and many people don't even have a PC in the first place. Then comes the case of installing adb, setting it up correctly, and having a cable to connect the two, enabling debug mode, and doing the thing. This is much more like a service thing, than a do it yourself at home thing. Not much unlike "chip tuning" for cars.
This doesn't strictly require a PC. There's this trick with using the wireless debugging feature to connect the phone to itself. You can do it with a terminal app like Termux but Shizuku is a nice GUI that streamlines this process and exposes an API for other apps to use. After a quick web search I found https://github.com/samolego/Canta which is, again, a GUI app that uses Shizuku to uninstall apps via adb.
I agree that it's not easy, but anyone sufficiently annoyed by these non-otherwise-removable apps who is able to follow instructions should be able to get it done without needing a computer or special knowledge or messing with the command line.
The article claims the app can only be removed with root access, which requires more difficult and technical steps to attain than running an adb command. If uninstalling the app with adb works and doesn't result in the app being promptly reinstalled, then the article has a significant factual error.
Except uninstallining the app does not equal removing it, as you claim. Removing it from list of apps to load is not removal. Not to mention it resets back to installed and you have to rerun the command.
Samsung has an entire PR team who get paid to misrepresent things — you should at least get paid for what you’re doing. You’ve already admitted that it can’t be removed and if it takes some shell work you’re not even sure about to disable it, that almost certainly means it’s coming back on every update.
Yes, but for most people (I'd guess 99% or more), they would never know to use the above, and I'm those who did find a guide might have issues using adb on their likely Windows or MacOS machine.
I had a OnePlus whatever as a work phone in my last job. Every time I used adb to purge the OnePlus crap, it would somehow find its way back. Eventually I settled on disabling autoupdates from the play store, so it was stuck at whatever outdated, and hopefully broken, version the phone shipped with.
OK, I see that one can get a list of all installed packages via adb:
$ pm list packages
How does one know which are safe to disable? In the sense that there won't be unexpected side effects. Besides, not all the names make clear exactly what the package is for.
Each one needs inspected one by one - but there is always the chance that package names have been purposefully obfuscated. It's really quite the uphill battle.
that doesn't work for every package. Some packages aren't authorized to be disabled this way, i.e. you can't disable them this way.
* Some packages can technically be disabled this way, but they cause unrelated issues like the phone wasting processing resources, even overheating the device; or bootloops.
* Less relevant, but the
package is disabled, but removed. The system can still reenable it, reinstall it, or upgrade it.
* Edit: I can't find a way to format this. It shows as a text block.
How would one go about using adb? Motorola, stock Android. Do I need to root my phone for this to work or what are the requirements, or how do I perform it?
You also have to enable developer options (tap the Android build number N times) and then enable USB debugging. You can disable USB debugging and the developer options afterwards (keeping USB debugging on is insecure).
The universal android debloater makes uninstalling packages easier, it has descriptions and categorizes packages by how safe they are to uninstall.
Using adb directly runs it under your user, which will probably be unable to access the necessary USB device.
Starting the server manually under a privileged user is the easiest way to circumvent those restrictions if you don't want to fiddle with udev rules, which is the recommended solution, but is more work.
It only works for me with one of my two USB ports, and my Kobo ereader has the same issue. Not sure why, best guess is one might be USB 2.0 and the other 3.0
Not sure what the issue was, I did not debug it. I will try again and see if it works or not, and will debug it further if it does not work. Arch Linux or Void Linux definitely should offer the same or more (or better) support.
