Potential main-thread ContentResolver query in Amaze file search flow

Hi Amaze File Manager Team,

I’m a PhD student researching Android performance issues. My research group recently ran a static analysis scan for thread-affinity and main-thread blocking bugs in real-world Android apps, and our prototype flagged a potential issue in Amaze File Manager.

This report is source-confirmed against the current GitHub source snapshot referenced below. I did not dynamically reproduce an ANR/crash, so this should be treated as a source-confirmed main-thread blocking risk rather than a reproduced runtime failure.

Checked target

• Repository: TeamAmaze/AmazeFileManager
• Source-level caller: com.amaze.filemanager.ui.views.appbar.SearchView#indexedSearch
• Detected API / pattern: android.content.ContentResolver#query
• Underlying platform APIs: ContentResolver#query(...)
• Observed context: search UI path / main thread
• Expected context: worker/background thread before blocking I/O, database, media preparation, bitmap compression, or slow system-service work

What I found

The current source still contains a path where com.amaze.filemanager.ui.views.appbar.SearchView#indexedSearch reaches android.content.ContentResolver#query synchronously. The concern is that this operation can block on local storage, a content provider, database work, media preparation, bitmap encoding, or a system service. When this path is executed from the main thread, the UI thread may be delayed.

Verified bug trace

User interacts with search UI
  -> SearchView#indexedSearch(...)
  -> ContentResolver#query(...)
  -> provider / MediaStore / storage lookup
  -> main thread waits for query result

Why this matters

This path is likely user-visible because it can run while the app is opening a screen, loading UI data, importing user-selected content, resolving provider metadata, or handling a user action. Android’s ANR guidance lists slow I/O, long calculations, and synchronous Binder calls on the main thread as common ANR patterns. In this case the risky operation is UI freeze during search, content-provider IPC/storage delay, possible ANR on large media stores.

Possible fix

Run the indexed search query on Dispatchers.IO or a dedicated executor, then post the result list back to the UI thread.

A typical structure is:

lifecycleScope.launch {
    val result = withContext(Dispatchers.IO) {
        // perform database/content-provider/file/media work here
    }

    // update UI here on the main thread
}

For non-UI classes, use a dedicated executor, repository-level coroutine scope, or existing background worker. The important point is to avoid performing the blocking operation synchronously on the main thread.

Reference

Android ANR guidance:

https://developer.android.com/topic/performance/vitals/anr

API-specific reference:

https://developer.android.com/topic/performance/vitals/anr

Source references

Current source snapshot:

https://github.com/TeamAmaze/AmazeFileManager/blob/840eef133906a9b85de08d41b562569b4082d318/app/src/main/java/com/amaze/filemanager/ui/views/appbar/SearchView.java#L316