[Bug] Potential Main thread blocking via synchronous ContentResolver#query in DocumentUri.kt

Hi Material Files 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, and our prototype flagged a potential issue in Material Files.

Checked target

• APK-level caller: me.zhanghai.android.files.file.DocumentUriKt#getDisplayName-B0AdpUI
• Detected API: android.content.ContentResolver#query
• Observed context: main/UI thread
• Expected context: worker/background thread

What I found

The analyzer reported that the app call:

contentResolver.query(

from a main/UI-thread path.

Verified bug trace

me.zhanghai.android.files.file.DocumentUriKt#getDisplayName-B0AdpUI
  -> source location: app/src/main/java/me/zhanghai/android/files/file/DocumentUri.kt:43
  -> source call: contentResolver.query(
  -> ContentResolver dispatches synchronous provider/storage work
  -> backing provider may perform Binder, disk, or document-provider I/O before returning
  -> analyzer/source audit observed context: main/UI thread
  -> expected context: worker/background thread
  -> possible UI freeze / delayed response / jank / ANR risk

Source context used for verification:

41:     get() {
  42:         try {
> 43:             contentResolver.query(
  44:                 value, arrayOf(DocumentsContract.Document.COLUMN_DISPLAY_NAME), null, null, null
  45:             ).use { cursor ->

Why this matters

Running the I/O operations synchronously on the UI thread can make Material Files feel frozen or delayed on slower devices, large datasets, or slow providers.

Possible fix

A possible fix is to move the blocking I/O, database, media, or system-service operation to a worker context and post only UI updates back to the main thread.

lifecycleScope.launch {
    val result = withContext(Dispatchers.IO) {
        performBlockingOperation()
    }

    renderResult(result)
}

Reference

• Source evidence: app/src/main/java/me/zhanghai/android/files/file/DocumentUri.kt:43
• Reference: https://developer.android.com/reference/android/content/ContentResolver#query(android.net.Uri,%20java.lang.String[],%20java.lang.String,%20java.lang.String[],%20java.lang.String)

Start at app/src/main/java/me/zhanghai/android/files/file/DocumentUri.kt:43 and inspect DocumentUriKt#getDisplayName-B0AdpUI plus its callers to confirm the thread context around ContentResolver#query. Determine how the existing code handles background work, then verify that the query no longer blocks the main/UI thread while display-name behavior remains unchanged.