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

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.

Start in app/src/main/java/com/amaze/filemanager/ui/fragments/CompressedExplorerFragment.kt at prepareCompressedFile(), around line 286, and trace whether callers reach it from UI callbacks. Review the project's existing background/IO pattern before changing the synchronous ContentResolver query. Done means the query no longer blocks the UI path, UI updates return to the main thread, and the current flow is verified.