AppManager icon indicating copy to clipboard operation
AppManager copied to clipboard

Interceptor Feature Breaks `android.intent.action.OPEN_DOCUMENT` Intent Permanently

Open TangoMan75 opened this issue 2 months ago • 3 comments

Please check before submitting an issue

  • [x] I know what my device, OS and App Manager versions are
  • [x] I know how to take logs
  • [x] I know how to reproduce the issue which may not be specific to my device

Describe the bug

AppManager's Interceptor feature appears to hijack and permanently remove the system's ability to handle the android.intent.action.OPEN_DOCUMENT intent, even after disabling the feature or uninstalling AppManager.

This intent is essential for Android's Storage Access Framework (SAF), which allows apps to open and save files via the system picker. When Interceptor is active, apps like Dropbox (using "Save to device") and NewPipe (during media downloads) will fail with a android.content.ActivityNotFoundException.

Attempts to Fix:

  • Disabling Interceptor via:
    • AppManager > Settings > Appearance > Enable/disable features > Uncheck Interceptor
  • Uninstalling AppManager
  • Resetting app preferences via:
    • Settings > Apps > Three-dot menu > Reset app preferences

None of these steps restore the intent.

Workaround:

Reinstall the default SAF provider:

  • Install "Files" (com.google.android.documentsui) from [APKMirror](https://www.apkmirror.com/apk/google-inc/files-6)

Environment:

  • Android version: 13
  • AppManager version: 4.0.5
  • Affected apps: Dropbox, NewPipe, others using SAF

Suggested Fix:

Interceptor should not permanently remove system intents. Consider isolating its effects or providing a safe rollback mechanism.

To Reproduce

  1. Install AppManager (io.github.muntashirakon.AppManager)
  2. Ensure Interceptor is enabled (default setting)
  3. Attempt to use a file picker in any app relying on OPEN_DOCUMENT (e.g., Dropbox, NewPipe)
  4. Observe the crash or failure to open the file picker

Expected behavior

Expected Behavior:

Apps should be able to invoke the system file picker without interference after disabling the Interceptor feature or uninstalling AppManager.

Actual Behavior:

Intent is hijacked and removed, causing apps to crash or fail to access files.

Screenshots

No response

Logs

android.content.ActivityNotFoundException: No Activity found to handle Intent { act=android.intent.action.OPEN_DOCUMENT ... }

Device info

  • Device: Probably multiple devices affected (Reproduced on OnePlus Nord and Galaxy S20 FE 5g)
  • OS Version: Android 13
  • App Manager Version: 4.0.5
  • Mode: NonRoot

Additional context

No response

TangoMan75 avatar Oct 07 '25 09:10 TangoMan75

It's likely due to a bug in your operating system that mishandles the SAF feature. Since App Manager is a user app, App Manager shouldn't even be considered as a handler for the SAF operations, which is the case if your OS worked correctly. For many years, the AOSP didn't adequately test the SAF features. So, it is likely that some developer introduced the bug that resulted in this unexpected behavior.

MuntashirAkon avatar Oct 13 '25 17:10 MuntashirAkon

You are correct, this bug is probably present on multiple operating systems, so far I encontered it in :

  • Oxygen OS 11 (OnePlus)
  • Oxygen OS 12 (OnePlus)
  • Android 13

I believe it would be safer to disable Interceptor feature by default, it is an advanced feature that most people won't use anyway. And maybe provide a tool to restore default SAF operations inside the app.

TangoMan75 avatar Oct 14 '25 09:10 TangoMan75

Let's assume an app intentionally implements a proper spoofed response. Forwarding (or "forwarding") uninteresting stuff and only intercepting things with potential for abuse. While I can't test it myself, that still sounds more like a vulnerability than a simple bug. Doesn't even need to be a malicious file of some sort returned. Even without abusing unexpected strings as response, that's still a DoS at the very least ?

Although given that many Intents can easily be intercepted without root... that's probably not something I'd want to think about too much (in terms of what else there might be to discover - API36+ is "fortunately" working on it)

TotallyAvailable avatar Oct 14 '25 15:10 TotallyAvailable