Potential Main thread blocking via synchronous SQLiteDatabase#rawQuery in SavedParcelTable

[venkyqz]

Description

Hi WordPress Android 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 WordPress Android.

Checked target

• APK-level caller: org.wordpress.android.editor.savedinstance.SavedParcelTable#getParcel
• Detected API: android.database.sqlite.SQLiteDatabase#rawQuery
• Observed context: main/UI thread
• Expected context: worker/background thread

What I found

The analyzer reported that the app call:

val c = db.rawQuery("SELECT * FROM $SAVED_PARCEL_TABLE WHERE $PARCEL_ID ='$parcelId'", null)

from a main/UI-thread path.

Verified bug trace

org.wordpress.android.editor.savedinstance.SavedParcelTable#getParcel
  -> source location: libs/editor/src/main/java/org/wordpress/android/editor/savedinstance/SavedParcelTable.kt:42
  -> source call: val c = db.rawQuery("SELECT * FROM $SAVED_PARCEL_TABLE WHERE $PARCEL_ID ='$parcelId'", null)
  -> app database layer performs a synchronous SQLite/query/cursor read
  -> cursor/database processing is reached from the reported thread context
  -> 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:

40:     fun <T> getParcel(readableDb: SQLiteDatabase?, parcelId: String, creator: Parcelable.Creator<T>): T? {
  41:         val db = readableDb ?: return null
> 42:         val c = db.rawQuery("SELECT * FROM $SAVED_PARCEL_TABLE WHERE $PARCEL_ID ='$parcelId'", null)
  43:         return try {
  44:             if (c.moveToFirst()) {

Why this matters

Running I/O operations synchronously on the UI thread can make WordPress Android 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: libs/editor/src/main/java/org/wordpress/android/editor/savedinstance/SavedParcelTable.kt:42
• Reference: https://developer.android.com/reference/android/database/sqlite/SQLiteDatabase#rawQuery(java.lang.String,%20java.lang.String[])

Please confirm that you have searched existing issues in the repo.

• Yes

[dangermattic]

🚫 Please add a type label (e.g. [Type] Enhancement) and a feature label (e.g. Stats) to this issue.

[adalpari]

Hi @venkyqz thank you very much for taking the time to report this issue.
We have taken a look, and your point is right. However, we don't think this is real bug in the current app state. So we are closing it as non-planned.

The query is a single-row lookup by primary key on a tiny, transient table — the I/O cost is negligible, so there's no realistic ANR or jank. More importantly, the call sites can't safely go async: onSaveInstanceState() must persist synchronously before the process dies, and onCreate()/newInstance() need the parcel immediately to restore editor state. Deferring them to a coroutine would risk losing state on process death — trading a near-theoretical performance concern for real state-restoration bugs.

Feel free to report any other issue you might find.

[venkyqz]

Hi @venkyqz thank you very much for taking the time to report this issue. We have taken a look, and your point is right. However, we don't think this is real bug in the current app state. So we are closing it as non-planned.

The query is a single-row lookup by primary key on a tiny, transient table — the I/O cost is negligible, so there's no realistic ANR or jank. More importantly, the call sites can't safely go async: onSaveInstanceState() must persist synchronously before the process dies, and onCreate()/newInstance() need the parcel immediately to restore editor state. Deferring them to a coroutine would risk losing state on process death — trading a near-theoretical performance concern for real state-restoration bugs.

Feel free to report any other issue you might find.

@adalpari Hi, thanks for the comprehensive explanations. Sorry that this is a general drawback of static analysis. It can identify potential problems but sometimes fail to show the significance. I will continue reporting bugs if our tool finds more…