I've noticed that apps (such as Google Contacts Sync) that have been disabled using the stock Android (KitKat) app manager still show up as running when using process observer tools. This is true even after the device has been rebooted.

Why are disabled apps still running? Is there an effective (and safe) way to actually disable them?

Solutions requiring root privileges are acceptable.

(Note that for the specific example above, you can tell Android not to sync your contacts, but it still runs the Google Contacts Sync process. But let's not dwell on that example... it's just an example.)

  • Right next to the "Disable" button is a "Force Stop" button. Press it and the process should terminate and not start anymore.
    – GiantTree
    Commented Nov 20, 2015 at 21:39
  • @GiantTree Thanks. After a reboot, won't it just start again? Commented Nov 20, 2015 at 21:40
  • 4
    In your case it does, because a system app has explicitly called an exported service of that package and the only way to reliably kill that process (and any other) is by actively killing it using Greenify, Amplify (requires Xposed) or similar apps. Note: that this should not happen and should be considered a bug, because the PackageManager has the task to not allow a disabled app to run.
    – GiantTree
    Commented Nov 20, 2015 at 21:49
  • 1
    Well in that regard, I disabled all the services, receivers, activities and the content providers as well as disabled the SystemUI app. Restarted the device and guess what the app still got loaded into the memory (such is not the case with pm block/hide) which makes me wonder what's causing the app to be loaded now. It is another matter that while it was loaded in the memory you can observe its superficial absence by lack of background, themes, status bar and more. Perhaps, a new question can be forged out of this.
    – Firelord
    Commented Nov 21, 2015 at 1:20
  • 1
    @Firelord I guess that's what I pointed out above: if you disable an app it's just "marked disabled" (and not shown in launcher etc) – but it's still registered with the system (package manager), so other apps can find it and call its intents. It seems like hiding/blocking is rather comparable with an "uninstall leaving .apk and data behind" – so the app gets "completely unregistered and invisible to everything but the file manager", so other apps are no longer able to call its intents as they can't find them.
    – Izzy
    Commented Nov 21, 2015 at 12:07

1 Answer 1


Your Android need not to have root access for truly disabling an app, if you've version 4.4.x or above. All you need is setup in PC and USB debugging enabled in a non-rooted device, or a terminal emulator app for a rooted device (you can use adb too).

If you check Package Manger's (pm) usage, you would see

pm block [--user USER_ID] PACKAGE_OR_COMPONENT")
pm unblock [--user USER_ID] PACKAGE_OR_COMPONENT")

For Lollipop, it would be

pm unhide [--user USER_ID] PACKAGE_OR_COMPONENT")

In order to block or hide a package (it is safe), simply do

pm block PACKAGE # for KitKat
pm hide PACKAGE  # for Lollipop

To unblock or unhide the package, do

pm unblock PACKAGE #for KitKat 
pm unhide PACKAGE  # for Lollipop

PACKAGE → package name of an app. To know the package name of an app:

Append adb shell before very command to execute them from PC.

The function behind hide has the following comment inside the source code

Puts the package in a hidden state, which is almost like an uninstalled state, making the package unavailable, but it doesn't remove the data or the actual package file. Application can be unhidden by either resetting the hidden state or by installing it

Similar commenting is done for block here.

In order to verify the claim, you can use some system services such as meminfo, procstats and activity using the dumpsys tool or even list all the processes using ps. You won't find an active presence of the blocked/hidden app.

The same goes for a lot of system apps disabled using GUI or pm disable but not for every app since even a disabled app can receive broadcasts it has registered for, which can only be done if it is loaded into the memory1. Nevertheless, a disabled app cannot act on its own, neither can it be executed by any other app.

I've argued some of the differences between hide/block and disable on my question pm hide VS pm disable -- the identity crisis. It provides only supplementary info to this answer so you may skip it.


It appears that the technique doesn't work for all apps on Android KitKat. In that case, simply revoke read permission from app's APK or remove the extension .APK from the file name of the app (latter suggested by Jaskaranbir once), followed by a soft/full reboot. This is same as deleting an app from system, with only difference that all files would remain at their place.

Both of the steps can be executed using any root file manager app. The command line way is:

adb shell su -c 'chmod 000 /data/app/PACKAGE*'             # 000 means no read-write-executable permission to user,group and others. 
adb shell su -c 'mv /data/app/PACKAGE* /data/app/PACKAGE'  # doing renaming by moving the file
adb reboot

1: Lacking technical evidence to support the fact

  • Great answer! Thank you! Is it best to first disable the app using the stock Android app manager, or best to make sure it is not disabled there? Commented Nov 21, 2015 at 0:38
  • There is no need to disable the app if you're opting for pm block/hide so leave it untouched.
    – Firelord
    Commented Nov 21, 2015 at 0:40
  • If it's already disabled, is it best to re-enable it? Commented Nov 21, 2015 at 0:43
  • 1
    This is bizarre. I tested blocking systemui on my Kitkat and to my surprise, block is working just like disable, this app stays in the memory. SystemUI process got forked even if I killed it. Don't know it's a bug or desired behavior, but in any case, it is in contrast to my Lollipop related findings stated in the answer. I guess the answer is pretty useless now.
    – Firelord
    Commented Nov 21, 2015 at 19:39
  • 1
    @RockPaperLizard, I forgot to tell you a very simple trick. Revoke read permissions of the package file (or base directory, in case of Lollipop), restart and done for good. For example, with root permissions, you can stop SystemUI in this fashion, adb shell su -c "chmod 111 /system/app/SystemUI.apk". 111 means set only executable permissions for owner, group, and others. Reboot and the app will be missing to the system. You can set it to 000 as well.
    – Firelord
    Commented Nov 23, 2015 at 6:01

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .