diff --git a/help/en/img/unsupported_android_version_warning.webp b/help/en/img/unsupported_android_version_warning.webp new file mode 100644 index 0000000..e6d6e27 Binary files /dev/null and b/help/en/img/unsupported_android_version_warning.webp differ diff --git a/help/en/index.html b/help/en/index.html index 20571a6..71ed4a3 100644 --- a/help/en/index.html +++ b/help/en/index.html @@ -87,6 +87,8 @@

Contents

  • Why PMX requires root or ADB access?
  • My device isn't rooted. How can I use PMX?
  • What are hidden APIs?
    • +
  • Why does PMX not run or work properly on the latest Android?
    • +
  • Why does PMX not work properly on OEM operating systems or custom ROMs?
  • How does PMX change other apps permissions?
  • Do the permissions remain changed after ADB is turned off, or root is denied, or PMX is uninstalled?
  • Why can't I change XYZ permission?
    • @@ -421,6 +423,7 @@

    Limitations of ADB

    However some OEMs add extra settings to control ADB's privileges. For instance you need to uncheck "Disable Permission Monitoring" on Oppo phones and "Allow granting permissions" in Security Settings on Xiaomi phones. See this question for more details.

    The following instructions apply to near-AOSP ROMs. Customized ROMs might have different or missing settings.

    +

    See Why does PMX not work properly on OEM operating systems or custom ROMs?

    @@ -623,6 +626,21 @@

    FAQs

    +

    Why does PMX not run or work properly on the latest Android?

    +

    PMX relies on Android's hidden APIs or non-SDK interfaces (see What are hidden APIs?) which are not documented (on Android Developers) unlike standard APIs. So with every new Android release, we have to go through the Android source code to find out which APIs have broken (changed or removed).

    +

    Also, it takes time to fix the broken APIs; sometimes weeks, sometime months. And it's not guaranteed that we'll always be able to fix the broken APIs. Sometimes Google on purpose makes it difficult or impossible for us to keep using the hidden APIs.

    +

    Therefore it's not possible for us to make the PMX immediately work on every new Android release (particularly in beta phase) as long as the final AOSP source code is not publicly released (on Code Search or Git Repository).

    +

    PMX's final supported Android version is stated in app description on GitHub and Play Store. When you run the app on an unsupported version for the first time, it shows a warning like this:

    + + +
    + +

    Why does PMX not work properly on OEM operating systems or custom ROMs?

    +

    PMX relies on Android's hidden APIs or non-SDK interfaces (see What are hidden APIs?) which are not documented (on Android Developers) unlike standard APIs. So we need access to the source code of your ROM to know exactly how the hidden APIs work.

    +

    Well, AOSP (which is developed by Google) is open-source. But if your OEM or ROM developer makes some changes to AOSP for the customization purpose, we've no way to know exactly what changes they have made to the stock AOSP code. We're quite helpless here. And this fact is stated in app description on GitHub and Play Store. Sorry.

    + +
    +

    How does PMX change other apps permissions?

    PMX itself cannot and does not grant or revoke other apps' permissions. In fact no third party app is privileged to do that. It's the Android OS which controls apps' permissions. PMX just sends a request to the Android framework to change a permission's state. Now it's entirely up to Android how much it honors our request. Not all permissions are changeable. And if you are not able to change a permission's state using PMX, you won't be able to change it in any other way either.

    @@ -656,7 +674,7 @@

    FAQs

  • Some AppOps are dependent on their corresponding manifest permissions. So they cannot be changed independently. For instance you may not be able to deny READ_CONTACTS AppOp if android.permission.READ_CONTACTS manifest permission is granted.
  • Some AppOps are only used by Android for compatibility (e.g. LEGACY_STORAGE) and they don't actually control anything. If we explore their underlying working it's revealed that granting / revoking such permissions doesn't make sense.
  • Some permissions cannot be changed if the app is running on or is targeting an older or newer Android version.
    • -
  • Some OEM ROMs behave weird when it comes to AppOps. We do not know exactly what changes your OEM has made to the stock AOSP code. That's why the statement on Github and Play Store: "The app is tested on stock Android 7-11. Some highly customized ROMs may behave unexpectedly."
    • +
  • Some OEM ROMs behave weird when it comes to AppOps. See Why does PMX not work properly on OEM operating systems or custom ROMs?
  • Many AppOps can have 2 modes: package mode and UID mode. It's possible that one can be changed while the other cannot be.

    • Actually there come many more explanations if we dig every app and permission individually (which doesn't sound practical). As stated above, PMX doesn't change other apps' permissions on its own. So even if for some unknown reason Android doesn't change a permission, or reverts it back immediately, there's nothing we can do to force it because these are the limitations at Android end. Rather, I should say this is how Android works.

    @@ -778,6 +796,7 @@

    FAQs

    Why do I get a lot of Bad ROM popups?

    OEMs make huge changes to stock AOSP code (which is developed by Google). So the AppOps framework on some custom / OEM ROMs returns unexpected results which PMX cannot understand. You can ignore these popups, but they mean that the functionality is somewhat limited.

    +

    See Why does PMX not work properly on OEM operating systems or custom ROMs?