anr-deadlock-detective

An input dispatching timeout means the main thread was blocked for about 5 seconds. Pull the ANR trace from /data/anr/traces.txt or adb bugreport, find the main thread's top frames, and match them to a cause such as disk I/O, a binder call, or a lock wait, then move that work off the main thread.

Locate the "main" thread in the trace and examine its top frames. Frames like Object.wait or LockSupport.park indicate waiting on a lock, Binder.transact indicates blocking IPC, and nativePollOnce means the main thread was idle so the cause lies elsewhere, such as the input dispatcher or another thread.

A runBlocking call on the main thread that awaits a coroutine scheduled on Dispatchers.Main deadlocks because the main thread is blocked and can never resume the awaited coroutine. Fix it by making the caller suspend-aware or moving the awaited work to Dispatchers.Default or Dispatchers.IO.

nativePollOnce means the main thread is idle in its message loop, not that it caused the ANR. The real cause is elsewhere: check recent binder calls, the input dispatcher state, other threads' activity, or system-level pressure on the device.

Yes. Calling SharedPreferences commit() on the main thread performs synchronous disk writes that can block long enough to trigger an ANR. Switch to apply(), which writes asynchronously, or migrate to DataStore for coroutine-based persistence.

Use recomposition or startup profiling when the screen merely feels slow or janky without an actual hang or ANR dialog. ANR analysis applies when the main thread is truly blocked, producing input dispatching timeouts, traces.txt entries, or Crashlytics ANR reports.