A Moto G that shipped in 2023 came with three separate Facebook apps installed: com.facebook.system, com.facebook.appmanager, and com.facebook.services. The owner had never once logged into Facebook on that phone. None of the three appear in the app drawer. All three had network permission, and two of them had permission to read device accounts. This is not a hypothetical. Motorola, along with more than 30 other manufacturers, has had a data-sharing arrangement with Meta that predates the phone’s first boot. The apps exist to support ad attribution deals, not to give you a Facebook client.

Most advice about preinstalled apps stops at “delete the bloatware.” That’s not specific enough to be useful, and it’s not always safe. Some system packages look like junk and are genuinely harmless to remove. Others look like junk and will quietly break your carrier’s VoLTE calling or your next OTA update. The difference matters more than the general advice admits.

three tiers, not one

Every preinstalled package on your phone falls into roughly three buckets.

Safe to remove. Carrier-branded apps that duplicate something Google already provides: a second app store, a “device help” app, a redundant weather widget, a “my [carrier]” account app you’ve never opened. These are almost always safe because they were bolted on by the carrier or OEM after the fact, not compiled into the base image.

Disable only, don’t uninstall. Anything tied to a hardware feature you might need later: NFC payment services, a fingerprint enrollment helper, the SIM toolkit (com.android.stk), or manufacturer-specific camera processing libraries. Disabling freezes the app and its network activity without touching the partition it lives on. If it turns out you needed it, re-enabling takes ten seconds.

Never touch without research. Anything with “gms,” “systemui,” “phone,” or “telephony” in the package name. Google Play Services (com.google.android.gms) alone touches sign-in, push notifications, location for practically every third-party app, and Play Store functionality. Removing it doesn’t just break Gmail. It breaks apps that have nothing to do with Google, because they call GMS libraries for basic tasks like reCAPTCHA or in-app billing.

the carrier layer is worse than the OEM layer

OEM bloatware gets most of the attention because Samsung and Xiaomi ship dozens of their own apps. But carrier bloatware is a separate, uglier layer stacked on top. Verizon phones commonly carry com.verizon.mips.services, a “message plus” backend that keeps running even if you use a different SMS app. AT&T devices have shipped with com.att.dh (device help) that phones home usage diagnostics on a schedule independent of anything you do with the device. T-Mobile’s com.tmobile.pr.adapt has shown up in teardown reports sending analytics pings roughly every 90 minutes regardless of whether the associated app is opened.

None of these three packages are required for calls, texts, or data to work. They are business intelligence tools the carrier attached to the firmware because they can. This is the cleanest category of “safe to remove” you’ll find on a preinstalled app list, because the carrier’s own support documentation usually confirms the app is optional.

the adb method, and why it’s reversible

Without root, the reliable way to remove a stubborn system app for your user profile is:

adb shell pm uninstall --user 0 <package.name>

This doesn’t touch the system partition. It hides the app from your user account and stops it running, but the APK stays on the read-only system image. A factory reset brings it back. This is the safest version of “removal” available to a non-rooted phone, and it’s the version worth using for anything in the “safe to remove” or “disable only” tiers, since it gives you a clean undo if something unexpected breaks.

Actual deletion from the system partition requires root and a custom recovery, and it removes your undo button along with the app. Unless you’re flashing a custom ROM afterward, this isn’t worth the risk for 90 percent of preinstalled apps. The --user 0 method gets you the privacy benefit (no more running process, no more background network calls) without the failure mode of a bricked update path.

how to check before you touch anything

Before removing a package you don’t recognize, search the exact package name, not the display name. “Device Help” tells you nothing. “com.att.dh” tells you it’s an AT&T diagnostics tool with public documentation about what it collects. Package names are stable identifiers; marketing names are not, and manufacturers reuse friendly names across completely different apps from one firmware version to the next.

If a package name includes “gms,” “vending” (this is the Play Store’s real package name, com.android.vending), “systemui,” “telephony,” “phone,” “settings,” or the name of your specific chipset vendor (qualcomm, mediatek), leave it disabled at most, never uninstalled, until you’ve confirmed independently what it does.

the actual rule

Carrier apps with a company name and no clear hardware function are the safest category to remove on any phone. OEM duplicate apps (a second gallery, a second browser, a second app store) are the second safest. Anything with “gms,” “system,” or a chipset vendor’s name in the package is the one category where the ten minutes of research before you touch it will save you a factory reset later.