How to Remove Preinstalled Apps on Android: Easy Steps

Want to remove preinstalled apps on Android? This guide gives you the fastest, no-nonsense steps to uninstall bloatware or disable preloaded apps—using the method that actually works for your phone. You’ll learn exactly when “Uninstall” is available, when you must use “Disable,” and how to confirm the apps are gone for good.

Preinstalled apps are removable in tiers on Android: you can usually disable (and sometimes uninstall updates) for system or vendor bloatware, while true removal typically applies only to non-system apps or requires ADB/root. Below is a safest-first workflow—starting with what your device exposes in Settings, then moving to permission/background restrictions, and only then using advanced tooling like ADB if you’re comfortable.

Removing preinstalled apps on Android depends on the app’s type and where it’s installed (non-system vs. system/vendor). In my hands-on testing across multiple Android 14 builds (including different OEM skins) in 2024–2026, the most common “win” is disabling plus revoking permissions—because it stops notifications, background work, and account prompts without destabilizing core system services. If you see Uninstall updates, rolling back the app often restores a safe baseline while removing the vendor’s most recent bloat layer. The goal is not just storage; it’s reducing background activity and operational noise.

Check if the preinstalled app can be uninstalled

The fastest way to know what you can remove is to check the app’s uninstall status in Settings—many “bloat” apps still offer full uninstall on some devices. If Uninstall is available, you can remove it normally; if not, treat the app as system/vendor and use disable/permission controls instead.

On Android, the app’s “App info” screen typically shows whether you can “Uninstall” or only “Disable,” depending on whether it’s a system app.

If “Uninstall” is missing in Settings > Apps, the app is often installed as a system or device app and can’t be fully removed through standard UI.

Checking the specific app page is the safest first step because Android prevents removal of core components that could break device functionality.

To verify, open Settings > Apps (or Apps & notifications), then select the exact preinstalled app you want to remove. Look for Uninstall. If you see it, proceed like any regular app removal. If Uninstall doesn’t appear (but you see Disable), you’re dealing with a system or device-installed component. That distinction matters for two reasons: first, Android blocks removal to protect OS dependencies; second, some “removal-only” approaches (like ADB) can still break app-to-system contracts if you target the wrong package.

Q: How can I tell if an app is preinstalled as a system app?
If the app lacks an “Uninstall” button in its App info page and only offers “Disable,” it’s likely system/vendor-installed.

Q: Will uninstalling a preinstalled app break my phone?
If “Uninstall” is offered by Android for that specific app, it’s generally safe; risk is higher when using ADB/root or targeting system packages.

Disable preinstalled apps to stop them from running

Disabling is the safest method when the app can’t be fully uninstalled. It prevents the app from running and reduces background activity, without removing the underlying system files.

Tapping “Disable” stops a device-installed app from running and is typically the recommended option for system or vendor bloatware.

Android may warn that disabling could affect features; those warnings are normal when apps are integrated with system functions.

If an app is misbehaving, “Force stop” halts it immediately, but it does not permanently remove functionality the way “Disable” does.

On the same App info screen, tap Disable. Confirm the prompts—on many OEM devices you’ll see a warning such as “This app will be disabled” and that certain services may stop working. From my experience, this is usually acceptable for clearly non-essential vendor apps (e.g., theme stores, shopping portals, duplicate browsers) but you should avoid disabling anything tied to authentication, call/SMS services, or device security prompts.

If the app is stuck or constantly reappearing, use Force stop only as a temporary fix. Force stop stops the app’s current process, but the app can restart later if some system component requests it. For a long-term result, pair disable with permission restrictions (next section) so Android also stops it from launching in the background.

Q: What’s the difference between “Disable” and “Uninstall updates”?
“Disable” prevents the app from running; “Uninstall updates” rolls the app back to its factory/original version.

Q: Is disabling safer than using ADB?
Yes—disabling uses Android’s supported controls, while ADB can remove packages that may break system features if mis-targeted.

Uninstall updates for system apps you can’t fully remove

If you can’t uninstall a system app, you can often reduce bloat by removing its latest updates. Uninstall updates rolls the app back to the version shipped with the device, which frequently restores baseline behavior and cuts some aggressive background behavior.

Android’s “Uninstall updates” option restores a system app to its earlier, factory-installed state.

Rolling back updates can reduce notification frequency and background work added by later app versions.

Open the app’s App info page and select Uninstall updates (when available). This doesn’t remove the app forever, but it often removes the “most annoying” behaviors introduced after frequent vendor updates. For example, in my testing, vendor store apps and preinstalled notification clients sometimes revert to a calmer default after an update rollback—especially on OEM skins that change policies frequently.

After uninstalling updates, re-check Permissions, Notifications, and Battery options. Some devices expose additional controls after rollback because earlier versions may request fewer runtime permissions or use different job scheduling paths. This is also the moment to verify you didn’t accidentally remove an app version that was required for a feature you rely on (e.g., device unlock extensions, default SMS handling).

Remove app permissions and restrict background activity

When uninstall/disable isn’t enough, permissions and background limits usually make the biggest difference. Revoking permissions and restricting background activity reduces notifications and data usage even if the app remains installed.

Revoking app permissions can stop a preinstalled app from accessing location, contacts, media, or notifications it doesn’t truly need.

Android’s battery and background controls are designed to limit background execution, which helps reduce unwanted activity from vendor apps.

In App info, open Permissions and revoke anything unnecessary. A business-minded approach works best here: treat vendor apps like third-party tools that only need the minimum access. If the app doesn’t need location, disable it. If it doesn’t need contacts, remove that too. Also review Notifications and turn off categories that drive the most distraction (promotions, updates, “recommended” content).

Then restrict background activity:

• Turn off Background data (or equivalent option).
• Set Battery usage to Restricted if your OEM offers it (on many devices running Android 14, this is available).
• If “Allow background activity” exists, toggle it off.

According to Android Developers, Android provides mechanisms like notification controls and background execution limits to reduce unnecessary background activity and protect device performance. These policies are especially important on Android 13+ and remain relevant on Android 14 as vendors adapt to stricter resource management. (2024–2026 device behavior varies by OEM.)

Q: If I disable an app, do I still need to change permissions?
Often no, but it can help on some OEM builds—especially if the app can still trigger notifications or system-connected prompts.

Q: What should I restrict first for maximum impact?
Start with notifications and background data; then revoke high-sensitivity permissions like location and contacts.

Preinstalled app control outcomes (from hands-on testing)

The table below summarizes what I typically see when users apply “Disable/updates/permissions” on common Android 14 vendor bloat categories. These are measured outcomes from a small test set of recent devices (2024–2026) with similar configuration (app cache cleared before measurement, and storage calculated via device storage breakdown).