Potential main-thread database cursor access in Amaze editable file initialization flow

[venkyqz]

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.filesystem.EditableFileAbstraction#<init>
• Detected API / pattern: android.database.sqlite.SQLiteDatabase#rawQuery and Cursor#moveToFirst
• Underlying platform APIs: SQLiteDatabase#rawQuery(...), Cursor#moveToFirst()
• Observed context: file abstraction construction reachable from UI-side file operations
• 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.filesystem.EditableFileAbstraction#<init> reaches android.database.sqlite.SQLiteDatabase#rawQuery and Cursor#moveToFirst 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

UI/file operation builds EditableFileAbstraction
  -> EditableFileAbstraction constructor
  -> SQLiteDatabase#rawQuery(...)
  -> Cursor#moveToFirst()
  -> main thread waits for database 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 synchronous database lookup while constructing file metadata; possible jank or ANR when many files are inspected.

Possible fix

Avoid synchronous database access in the constructor; preload metadata on a worker thread and pass resolved metadata to UI objects.

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:

AmazeFileManager/app/src/main/java/com/amaze/filemanager/filesystem/EditableFileAbstraction.java

Line 68 in 840eef1

The result and whether [Cursor.getString()] throws an exception when the column