Main-thread misuse

The main-thread misuse detector flags I/O, network, database, or SharedPreferences operations executed on the UI thread — the kind of work that directly causes jank, hangs, and ANRs. When a violation is observed, Bugsee reports an issue with the offending stack trace categorized under one of six domains: DiskRead, DiskWrite, Network, Database, SharedPrefs, or generic Blocking.

Each unique call-site is reported once per session — repeated calls don't flood Bugsee with duplicates.

Requires the Bugsee Gradle plugin

Main-thread misuse is powered by bytecode instrumentation performed by the Bugsee Gradle plugin's mainThreadMisuse transform. The plugin injects lightweight pre-call checks before guarded I/O / network / DB / SharedPreferences calls, and the checks bridge to BugseeMainThreadGuardAdapter at runtime. Without the Gradle plugin, setting the option alone has no effect.

See the Gradle plugin page for setup instructions.

Configuration

Form	Setting
Manifest meta-data	<meta-data android:name="com.bugsee.option.detect.main_thread_misuse" android:value="true" />
Bugsee.launch() map	options.put(Options.DetectAndReportMainThreadMisuse, true)
Default	false

AndroidManifest.xml

<meta-data android:name="com.bugsee.option.detect.main_thread_misuse"
           android:value="true" />

Programmatic

HashMap<String, Object> options = new HashMap<>();
options.put(Options.DetectAndReportMainThreadMisuse, true);
Bugsee.launch(this, "<APP_TOKEN>", options);

What gets instrumented

The Gradle plugin's transform wraps these surface families:

• Disk read / write — java.io.FileInputStream / FileOutputStream, RandomAccessFile, Files.read* / write*.
• Network — Socket connect / read / write, HttpURLConnection.getResponseCode(), OkHttpClient.execute().
• Database — SQLiteDatabase.execSQL / rawQuery, SupportSQLite* (Room) equivalents.
• SharedPreferences — SharedPreferences.Editor.commit() (note: apply() is async, so it isn't flagged).
• Blocking — Object.wait, Thread.sleep, CountDownLatch.await when called on the main thread without a timeout.

Calls that are already wrapped in a known background-dispatch idiom (e.g. withContext(Dispatchers.IO), executor.submit(...)) won't trigger reports because the runtime check runs after the dispatch.

See also

• Configuration → Detection — the option-key reference for all detection options.