30

What's the need of pm disable when pm hide already does its job?

I've compiled some information based on my search and research: click here to see the table (edited).

As you can see, pm hide can achieve what pm disable can, but without needing root access. Also, based on my tests, I've reached the conclusion that when pm hide is performed, unlike pm disable, no matter what, the app will not be loaded in the memory again.

I opine that hide descended from block. Block was first introduced in KitKat 4.4.0, remained till Android L Preview and was later superseded by hide in Android 5.0.0. It is not clear to me what lead to renaming of block to hide and why was it needed?

Regardless, if somebody without root access can achieve the functionality of disable, then why does disable exists at all?

Furthermore, why does hide exists? If hide was built supposedly to help users to get rid of anything they want, without un-installation and without rooting the device, then in the GUI we should be having a relevant option, but we've got only the disable option.

Intertwine questions:

  • What are the merits and demerits of them, excluding those noted in my question?

  • Why both of them exists and to what or whom do they serve?

  • Is it technically true that hide surpasses the functionality of disable and can truly disable any app, when executed on it?

  • New: Given findings of Andrew T. and my tests shown in the table, is component shown in hide's usage an error or have I failed to understand latter's usage?

    For historical purposes: hide's usage as of now is shown as

      pm hide [--user USER_ID] PACKAGE_OR_COMPONENT
    

Note: The question does not, in any fashion, seeks unsubstantiated opinion but straight to-the-point answer(s). If you must write an opinion, make sure to back it up using credible and technical sources with sound reasoning to make distinction between what is technical and real and what is speculative.


Tests performed on Carbon ROM (Android 5.1.1) and COS12 (Android 5.0.2) for OnePlus One.

7
  • 7
    Probably the biggest difference is, you can disable per-app component (activity, service, broadcast receiver, content provider) without disabling the app itself, but you can only hide the whole application. The pm usage is slightly confusing for hide, but the underlying code only process the whole package, not the component. In other word, hide is temporary uninstall -k.
    – Andrew T.
    Nov 16, 2015 at 3:36
  • 1
    That is interesting info. Now that you've mentioned this info, I would test and report whether hide can disable a component or not. Its usage seems a copy of disable: android.googlesource.com/platform/frameworks/base/+/…
    – Firelord
    Nov 16, 2015 at 3:47
  • 3
    That's why it's misleading; runSetEnabledSetting() checks for component name, but runSetHiddenSetting() only checks for package name. Not sure if it can hide component in the future though.
    – Andrew T.
    Nov 16, 2015 at 3:51
  • 1
    @AndrewT., thanks you for the information. My tests have shown results in accordance with your information. Please see the revised question including the edited table for further info. If possible at the moment, consider posting a formal answer.
    – Firelord
    Nov 16, 2015 at 21:45
  • 2

1 Answer 1

3

I don't have enough points to comment yet.. This is not an answer... more like... information:

pm hide does this

pm disable does this and if it can find the component name then this.

I can see how some people may have thought that pm hide would do an uninstall.

ex. If you run this command after a pm hide

diff <(adb shell pm list packages -u) <(adb shell pm list packages)

You'll see your hidden package. -u is a list of previously uninstalled packages.

These pm commands below all invoke androids Intent class.

pm hide <package>
pm unhide <package>
pm enable <package>
pm disable <package>

This command below:

pm hide <package>

invokes:

android.intent.action.PACKAGE_REMOVED.  

This below command:

pm unhide <package>

invokes:

android.intent.action.PACKAGE_ADDED.

pm disable and pm enable both invoke:

android.intent.action.PACKAGE_CHANGED.

Thanks @Irfan Latif for the corrections. I can verify what he was saying. Under Android Settings: If you look at installed apps, even after pm hide, you can still see the app is installed. Interestingly, with pm disable, the app disappears from installed apps. These commands don't seem to create any obvious filesystem changes.

These directories:

/mnt/sdcard/Android/data/
/data/data

and other misc directories...

One possible hypothesis... Maybe its best practice to always call both commands to disable any package:

pm disable <package>;pm hide <package>
5
  • 1
    pm hide is available on Android 9 and hiding an app doesn't uninstall it. All (or at least some partial) data is intact after unhide. Feb 27, 2020 at 22:50
  • I removed my Android 6 reference I removed it just seconds before you posted your comment, but thanks for that. According to this dude its the same as uninstall -k. github.com/blackbbc/Evil-Hide/blob/master/README_en.md and stackoverflow.com/a/21173985/3066563
    – Jeff Luyet
    Feb 27, 2020 at 23:01
  • 2
    pm uninstall -k deletes /data/app/<pkg> directory entirely, pm hide does not. Feb 27, 2020 at 23:09
  • But still your answer/information doesn't answer, at least, the first line of the question. Feb 28, 2020 at 7:54
  • Correct. So do you think it should be deleted then?
    – Jeff Luyet
    Feb 28, 2020 at 14:09

You must log in to answer this question.

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