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.

  • 5
    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 '15 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 '15 at 3:47
  • 1
    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 '15 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 '15 at 21:45
  • I'd guess, since disable required root so would enable. Having app disabled would then give better guarantees that no malicious app would be able to enable it. – JustMe Mar 18 '17 at 12:29

protected by Community Jul 1 at 2:17

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Browse other questions tagged or ask your own question.