> "unremovable"

> you can't completely remove it

Maybe my English isn’t very good but that sounds like the definition of unremovable.

Your English is perfect. The GP is a fool to try down play it and proved themselves wrong in the same sentence

...doesn't sound removed to me, there are still copies sitting on other phones and servers somewhere.

No, still not removed...the idea and possibility for implementation still exists in people's minds.

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.

It's in a read only filesystem. You can't modify read only data, but you can choose to ignore it.

Only because it is mounted as one. It is like saying that you can't have your house in pink because it is green.

If you modify a file on the partition the device will fail to boot. Your metaphor is not equivalent because it ignores security.

There’s an enormous difference between “it can’t be stopped” and “its storage area can’t be reclaimed” though.

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.

It's not being pedantic. Disabling the application does not give me the storage space back.

If people are paying for upgrades to storage space it's completely reasonable for them to be annoyed by bloatware

The system partition is usually the same size regardless of which storage option of the same phone model you get.

But if the system partition could be smaller, other partitions could be larger.

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.

Yes, but if the phone shipped with less bloatware on the system partition, then maybe that partition would be made smaller initially.

Meaning the user would have access to more of the phone’s advertised storage.

You have succeeded in splitting hairs down to the atomic level. Fissionable HN comments!!

Or perhaps there would be less incentive for the OEM optimize for disk space and it ends up taking the same amount of space.

Even with the outrageous prices for phone storage upgrade, an entire gigabyte of inactive bloat would be a $1 impact. It's not a big deal.

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.

Do you know if the same apps remain installed in "Secure Folder" as well?

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.

I've had a few Moto phones and have also been pleased with the fairly stock OS and durability.

So you're saying it can't be removed?

Don't even need that, you can disable it within the OS app settings.

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.

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.

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.

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.

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.

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.

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?

1. Install android SDK / android studio on your computer.

2. Plug phone in to computer using USBC cable.

3. Answer prompt on phone granting permission to computer.

4. Run adb commands.

Thanks, my issue so far was with the 2nd step, as if my Linux did not recognize my device. I might have a go on Windows if Linux will not work again.

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

That could very well be the issue. We will see. I think I only have 2.0 working right now. I hope it works with 2.0 too. :/

Knoppix has an old android adb and drivers. Still recognizes Samsung A and chinese androids and is functional.

Other dristros surely offer the same support

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.

Have you tried 'sudo adb start-server' before running any adb commands?

No. Do I have to?

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.

Thank you! Will keep it in mind! I have higher hopes now.

Check your udev rules

https://wiki.archlinux.org/title/Android_Debug_Bridge#Add_ud...

Thanks!

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.

It's not trivial for most and will most likely get reenabled after the firmware upgrade.

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.

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.