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 the WordPress Android app.
Checked target
- APK-level caller:
org.wordpress.android.editor.savedinstance.SavedInstanceDatabase#addParcel
- Detected API:
android.database.sqlite.SQLiteOpenHelper#getWritableDatabase
- Observed context:
main/UI thread
- Expected context:
worker/background thread
What I found
The analyzer reported that the app call:
SavedParcelTable.addParcel(writableDatabase, parcelId, it)
from a main/UI-thread path.
Verified bug trace
org.wordpress.android.editor.savedinstance.SavedInstanceDatabase#addParcel
-> source location: libs/editor/src/main/java/org/wordpress/android/editor/savedinstance/SavedInstanceDatabase.kt:48
-> source call: SavedParcelTable.addParcel(writableDatabase, parcelId, it)
-> 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:
46: fun addParcel(parcelId: String, parcel: Parcelable?) {
47: parcel?.let {
> 48: SavedParcelTable.addParcel(writableDatabase, parcelId, it)
49: }
50: }
Why this matters
Running such I/O operations synchronously on the UI thread can make WordPress Android feel frozen or delayed on slower devices, with 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
-libs/editor/src/main/java/org/wordpress/android/editor/savedinstance/SavedInstanceDatabase.kt:48
Please confirm that you have searched existing issues in the repo.
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 the WordPress Android app.
Checked target
org.wordpress.android.editor.savedinstance.SavedInstanceDatabase#addParcelandroid.database.sqlite.SQLiteOpenHelper#getWritableDatabasemain/UIthreadworker/backgroundthreadWhat I found
The analyzer reported that the app call:
SavedParcelTable.addParcel(writableDatabase, parcelId, it)from a main/UI-thread path.
Verified bug trace
Source context used for verification:
Why this matters
Running such I/O operations synchronously on the UI thread can make WordPress Android feel frozen or delayed on slower devices, with 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
-
libs/editor/src/main/java/org/wordpress/android/editor/savedinstance/SavedInstanceDatabase.kt:48Please confirm that you have searched existing issues in the repo.