Potential ANR / main-thread blocking risk: `query(...)` in `CompressedExplorerFragment.prepareCompressedFile() → ContentResolver-query`

[venkyqz]

Environment

• App: Amaze File Manager (com.amaze.filemanager)
• Branch checked: release/4.0
• File: app/src/main/java/com/amaze/filemanager/ui/fragments/CompressedExplorerFragment.kt:286
• Verified commit: e1e5619aee0a074023870e091299c831580ee0d7

The Issue

While reviewing CompressedExplorerFragment.prepareCompressedFile() → ContentResolver-query, I noticed a potential main-thread blocking risk around android.content.ContentResolver#query(android.net.Uri,java.lang.String[],java.lang.String,java.lang.String[],java.lang.String).

The latest source still performs the operation synchronously:

283:         if (ContentResolver.SCHEME_CONTENT == pathUri.scheme) {
284:             requireContext()
285:                 .contentResolver
286:                 .query(
287:                     pathUri,
288:                     arrayOf(MediaStore.MediaColumns.DISPLAY_NAME),
289:                     null,
290:                     null,
291:                     null,

android.content.ContentResolver#query(android.net.Uri,java.lang.String[],java.lang.String,java.lang.String[],java.lang.String) can block the calling thread while Android resolves a provider, opens a stream, performs database work, contacts account services, touches storage, or waits on remote I/O, depending on the API and URI/backend involved.

The Risk & Impact

If this method is reached from a UI-thread path, the operation can cause visible jank, StrictMode violations in debug builds, or an ANR when the provider/backend is slow, blocked, or unreachable. I am phrasing this as a source-level risk because I verified the current source pattern but did not run an on-device reproduction.

Current source path

<com.amaze.filemanager.ui.fragments.CompressedExplorerFragment: java.lang.String prepareCompressedFile(java.lang.String)>
  -> android.content.ContentResolver#query(android.net.Uri,java.lang.String[],java.lang.String,java.lang.String[],java.lang.String)

Next Steps / Verification Required

Please confirm whether this method can be reached from UI callbacks in the current app flow. If so, the blocking operation should be moved to the project’s existing background/IO pattern, with only UI updates posted back to the main thread.

Verification

I checked the latest upstream source at e1e5619aee0a074023870e091299c831580ee0d7 and found the sensitive operation still present in app/src/main/java/com/amaze/filemanager/ui/fragments/CompressedExplorerFragment.kt. This report is based on source-level inspection, not runtime reproduction.

[venkyqz]

I think this could be similar to #4610

[EmmanuelMess]

What tools are you using to generate these?

[venkyqz]

What tools are you using to generate these?

@EmmanuelMess I used my ongoing static analysis research prototype tool to identify such problems. Thanks for confirming the problem and asking that.

[EmmanuelMess]

I used my ongoing static analysis research prototype tool to identify such problems. Thanks for confirming the problem and asking that.

Do share your publication or thesis when its available.

[venkyqz]

I used my ongoing static analysis research prototype tool to identify such problems. Thanks for confirming the problem and asking that.

Do share your publication or thesis when its available.

Thank you for your support!