Main-thread misuse (7.x Beta)
APIs and defaults may still change before the 7.0 stable release.
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 categorised 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.
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
- Programmatic
<meta-data android:name="com.bugsee.option.detect.main_thread_misuse"
android:value="true" />
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 —
Socketconnect / 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.awaitwhen 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.