How to delete unwanted manufacturer built-in apps in Android phone/tablet?

Welcome to Blackview (World's well-known brand of rugged phone and tablet) blog. Hope this guide has been helpful.

Many Android phones and tablets come with applications installed by the manufacturer or carrier before the device reaches the user. Some are genuinely required for core Android functions, while others may be browsers, app stores, manufacturer marketplaces, media apps, promotional services, device-management tools, or duplicate versions of applications that the user never intends to use. The frustrating part is that an app can appear removable in every practical sense yet still show a greyed-out Uninstall button in Settings. Force-stopping it may also provide only temporary relief if another system component or scheduled process starts it again.

• Read also: How to completely close background apps on Android?
• How to clear cache on Android all at once?
• How to find missing app icon on you phone?
• How to check how much available RAM does phone have?

There are several ways to deal with these applications, ranging from completely safe methods such as disabling or uninstalling updates to more advanced approaches using Android Debug Bridge (ADB). The right method depends on whether the application is genuinely part of the operating system, merely preinstalled as a privileged package, or protected by the manufacturer's software configuration. Before deleting anything, identify the exact package and understand what it does. Removing a package that Android or the manufacturer's user interface actually depends on can cause crashes, missing settings, boot problems, or a device that requires a factory reset.

Why can't some built-in Android apps be uninstalled?

The Uninstall button being unavailable does not necessarily mean that an application is essential to Android. Manufacturers can place applications in protected system or product partitions, mark packages as privileged, or configure the device so that the normal Settings interface does not allow the user to remove them. A package can therefore be unnecessary for your personal workflow while still being treated as a preinstalled package by Android.

It is also important to distinguish between an application's APK being stored in a protected partition and the application being actively running. A preinstalled application may occupy some permanent storage even when disabled, but that does not automatically mean it is consuming RAM continuously. RAM usage should be checked separately in Android's battery, memory, or developer tools. Likewise, an application that launches briefly in the background does not necessarily remain permanently resident.

Start with the safest removal methods

Before using ADB or other advanced techniques, check what Android itself allows you to do. Depending on the manufacturer and Android version, you may find Uninstall, Uninstall updates, Disable, or only Force stop. These options have very different consequences.

Method 1: Uninstall normally

If the application is removable, the safest procedure is simply to use the standard Android interface:

• Open Settings and go to Apps, App management, or the equivalent menu.
• Find the unwanted application.
• Open its information page.
• Tap Uninstall.
• Confirm the operation and restart the device if necessary.

This method is preferable because Android handles the application's associated data and permissions through its normal package-management system.

Method 2: Disable the application

If Uninstall is unavailable but Disable is present, disabling is generally a safer alternative than manually deleting system files. Disabling can prevent the application from appearing in the launcher and stop it from being started normally. The exact behavior varies by manufacturer.

• Open Settings > Apps.
• Select the unwanted application.
• Tap Disable if the option is available.
• Confirm the warning.
• Restart the phone or tablet and check whether the application remains inactive.

Some manufacturers do not offer a Disable button for particular packages. In that case, ADB may provide more control without requiring root access.

Use ADB to remove or disable stubborn packages

ADB, or Android Debug Bridge, is an official Android development and troubleshooting interface that allows a computer to communicate with an Android device. For advanced users, ADB can often uninstall a preinstalled package for the current Android user even when the graphical Settings application refuses to provide an Uninstall button. This is significantly different from physically deleting the APK from a protected partition.

Step 1: Prepare the Android device

• Open Settings > About phone.
• Locate Build number.
• Tap Build number repeatedly until Developer options are enabled.
• Return to Settings and open Developer options.
• Enable USB debugging.
• Connect the phone or tablet to a computer with a suitable USB cable.
• Accept the computer's USB-debugging authorization prompt on the Android device.

Step 2: Identify the correct package name

The visible application name is not necessarily its package name. For example, an app displayed as a manufacturer browser could have a completely different internal package identifier. Identifying the exact package is critical because an incorrect ADB command can target a different application.

You can use Android development tools or package-listing commands to inspect installed packages. Do not guess a package name merely because it resembles the application's visible name. Verify the package carefully and, when possible, research its purpose using the device manufacturer's documentation or Android community resources.

Step 3: Remove the package for the current user

After ADB is correctly installed and the device is recognized, advanced users commonly use the Android package manager through ADB. The general command pattern is:

• Connect the device and verify that ADB recognizes it.
• Identify the exact package name.
• Use the package manager command to uninstall that package for the current user.
• Restart the device.
• Check whether the unwanted application and its background behavior have disappeared.

This approach can make a preinstalled application unavailable to the current user without modifying the protected system partition itself. Consequently, it is generally less invasive than rooting the device and manually removing files from system directories.

Why ADB removal is not always permanent

An important limitation is that an ADB-based removal for the current user may not mean the APK has disappeared from every partition of the device. A major Android system update, firmware update, factory reset, or manufacturer recovery process can potentially restore preinstalled packages. In other words, there is a difference between removing an application from your current user profile and erasing the manufacturer's copy of the application from the firmware.

For many users, this distinction is actually beneficial. If the application causes problems, you can potentially restore it later rather than permanently altering the operating system. It also avoids the substantially greater risks associated with rooting and modifying protected system partitions.

What about root access?

Root access gives the user considerably greater control over Android's filesystem and protected partitions. In theory, a rooted device can allow system applications to be removed at a deeper level. However, rooting is not simply a more powerful version of ADB. It can affect security protections, device integrity checks, OTA updates, warranty conditions, banking applications, DRM functionality, and the ability to recover from software failures.

For an unwanted browser or manufacturer app, rooting is usually unnecessary if disabling or user-level ADB removal achieves the desired result. If the objective is merely to stop an application from launching automatically and reclaim some practical storage, the least invasive method that works should generally be attempted first.

How to decide which apps are safe to remove

The most important step is identifying what an application actually does. A manufacturer browser, duplicate app marketplace, promotional application, or optional media application is fundamentally different from a package responsible for the launcher, Settings interface, telephony framework, permissions, package installation, or system UI.

• Usually lower risk: optional browsers, manufacturer shopping apps, duplicate app stores, promotional apps, and unused media applications.
• Use caution: cloud-sync services, account-management components, device-security tools, update utilities, and manufacturer frameworks.
• Do not remove casually: Android System, System UI, Settings, core package-management components, telephony services, permission controllers, and other packages whose purpose you cannot identify.

If an application has a vague name or package identifier, research it before taking action. Search for the exact package name together with the device model and Android version. Community reports can be useful for discovering dependencies, but manufacturer documentation and reproducible technical information should be preferred over an isolated claim that an application is “safe to delete.”

What if the app keeps restarting?

If an application restarts after Force stop, that behavior does not necessarily mean Android is malfunctioning. Another application, scheduled service, notification, account component, or manufacturer framework may be launching it. On some devices, manufacturer software is specifically designed to maintain certain services in the background.

Instead of repeatedly force-stopping the application, check whether Android provides Disable, restrict its background activity where appropriate, remove unnecessary permissions, and investigate which package is actually responsible for launching it. If the unwanted application is safely identified, disabling it or removing it for the current user through ADB can be more effective than repeatedly using Force stop.

Recommended approach

For most Android phones and tablets, use a gradual approach. First try normal uninstallation. If that is unavailable, try disabling the app. If neither option exists and you have confirmed that the package is optional, use ADB to remove it for the current user. Avoid rooting simply to remove one or two manufacturer applications unless you have a specific technical reason and understand the consequences.

The greyed-out Uninstall button does not by itself prove that an application is a critical system component. It often indicates that the manufacturer has preinstalled the package in a way that prevents ordinary removal. The safest solution is therefore not to delete random APK files, but to identify the package, determine its role, and use the least invasive removal method available.

For users dealing with persistent manufacturer browsers, duplicate app stores, promotional services, or similar unwanted software, ADB can provide a useful middle ground between ordinary Settings controls and full root access. Always verify the package name before removing it, keep a backup of important data, and remember that firmware updates or a factory reset may restore preinstalled applications.