9

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.)

End Anti-Semitic Hate
  • 4,400
  • 23
  • 61
  • 100
  • Right next to the "Disable" button is a "Force Stop" button. Press it and the process should terminate and not start anymore. – GiantTree Nov 20 '15 at 21:39
  • @GiantTree Thanks. After a reboot, won't it just start again? – End Anti-Semitic Hate Nov 20 '15 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 Nov 20 '15 at 21:49
  • Thanks! That is great information. I have updated the question to reflect that root solutions are acceptable. Can I use a tool like MyAndroidTools to manually disable all the services for the disabled apps? – End Anti-Semitic Hate Nov 20 '15 at 22:16
  • @Firelord Thanks. Does hide work in KitKat, or was it introduced in Lollipop? Can the hide command be executed directly from the device, or does it require an external adb connection? After performing that command, what is the command to reverse it, if needed? – End Anti-Semitic Hate Nov 20 '15 at 23:08
  • @Firelord mind compiling your comments into an answer? Though the question asks "why", I think the "how to prevent" was the real question (for the why: disabled apps can still have their intents called – which happens quite often for central Google apps. According to your (linked) research, this should no longer apply once the app was blocked/hidden). – Izzy Nov 20 '15 at 23:20
  • If you succeed using my answer, please do let me know since I've tested my solution only on Lollipop ROMs. – Firelord Nov 21 '15 at 00:41
  • @Izzy and Firelord Asking this to learn more: Would using a tool like MyAndroidTools to disable all the services and receivers for the app be another effective solution? – End Anti-Semitic Hate Nov 21 '15 at 00:42
  • 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 Nov 21 '15 at 01: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 Nov 21 '15 at 12:07
  • @Izzy Except that blocking apparently does not work properly in KitKat. :-( – End Anti-Semitic Hate Nov 22 '15 at 06:24
  • @RockPaperLizard … and hiding doesn't work there at all. Well, the doom of KK seems not to be limited to dealing with your SD card. Sorry for that. But I was "speaking generally" ;) – Izzy Nov 22 '15 at 09:04

1 Answers1

7

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 hide [--user USER_ID] PACKAGE_OR_COMPONENT")
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.

EDIT:

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

Firelord
  • 25,084
  • 20
  • 124
  • 286
  • 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? – End Anti-Semitic Hate Nov 21 '15 at 00:38
  • There is no need to disable the app if you're opting for pm block/hide so leave it untouched. – Firelord Nov 21 '15 at 00:40
  • If it's already disabled, is it best to re-enable it? – End Anti-Semitic Hate Nov 21 '15 at 00:43
  • There is no need to do that. The hide attribute would be set beside the disable attribute for that package (you can check it inside /data/system/users/0/package-restrictions.xml, look for <pkg name="YOUR_PACKAGE"). In short, it is safe whether you apply the block/hide command on a disabled app or not. – Firelord Nov 21 '15 at 00:49
  • I tried it. Here's the response received in the terminal emulator (verbatim): "WARNING: linker: app_process has text relocations. This is wasting memory and is a security risk. Please fix. Killed" – End Anti-Semitic Hate Nov 21 '15 at 11:28
  • Hmmm... It doesn't seem to be working. Tried it on 3 packages. They continue to load and run. – End Anti-Semitic Hate Nov 21 '15 at 12:31
  • "WARNING: linker: app_process has text relocations. This is wasting memory and is a security risk. Please fix. Killed" -- do you have Xposed installed? I used to have this warning because of that. As for whether they are working or not, I can't confirm for sure because in my comment on your question I did say that my finds are based on Lollipop but block should be working regardless. I'll see what else I can find to help here. – Firelord Nov 21 '15 at 18:59
  • 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 Nov 21 '15 at 19:39
  • @Izzy Pinging you to make you aware of the chat, as you may be interested. – End Anti-Semitic Hate Nov 21 '15 at 21:03
  • 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 Nov 23 '15 at 06:01
  • Great idea. See chat link above for continuation... – End Anti-Semitic Hate Nov 23 '15 at 08:22
  • I performed a little more testing, and the message "WARNING: linker: app_process has text relocations. This is wasting memory and is a security risk. Please fix. Killed" appears whether using pm to block or unblock. It also appears when using a fictional package name. I wonder, in KitKat, if it is doing anything. – End Anti-Semitic Hate Nov 29 '15 at 03:20
  • You may want to update your answer to make it clear that this technique apparently does not work in KitKat. Also is it only Broadcast Receivers that can load a disabled app, or will Services load it as well? See: http://android.stackexchange.com/questions/131499/does-android-swap-out-memory-used-by-foreground-services – End Anti-Semitic Hate Dec 14 '15 at 20:09