The main thread, Looper and Handler

The loop in a few lines

Most threads have no Looper. You can give one a loop yourself, which is exactly what the framework does for the main thread:

1val worker = thread {2    Looper.prepare()                                  // attach a MessageQueue to this thread3    handler = Handler(Looper.myLooper()!!)            // a way for other threads to post into it4    Looper.loop()                                     // run messages until quit() is called5}

In practice you use HandlerThread for this, or more often coroutines, but the model is the same one the main thread uses.

Posting work

A Handler is a handle onto one Looper's queue. Any thread can use it to enqueue work for that Looper's thread:

1val main = Handler(Looper.getMainLooper())2 3main.post { statusText.text = "Done" }                 // run as soon as the queue gets to it4main.postDelayed({ hideBanner() }, 3_000)              // run no earlier than 3 seconds from now

postDelayed is "no earlier than", not "exactly at": if the main thread is busy, the message waits. Also note that pending messages hold references to whatever their lambdas capture; remove them (removeCallbacksAndMessages(null)) when the screen goes away, or prefer a lifecycle-aware coroutine.

View.post {} and Activity.runOnUiThread {} are shortcuts for the same thing.

The budget

At 60 Hz a frame has about 16 ms; at 120 Hz about 8 ms. Any message that runs longer than that delays the next frame, which users notice as jank. Long-running blocking work belongs on other threads: networking (which throws NetworkOnMainThreadException on the main thread), database queries, file I/O, JSON parsing of large payloads, bitmap decoding.

ANRs

If the main thread stays blocked, the system steps in. The documented triggers include:

• an input event (touch, key) not handled within 5 seconds;
• a BroadcastReceiver that hasn't finished in time (5 seconds while the app has an activity in the foreground, longer otherwise);
• a service whose onCreate/onStartCommand/onBind doesn't return within a few seconds;
• a service started with startForegroundService() that doesn't call startForeground() within 5 seconds.

The cause is often not slow code but a wait: a lock held by a background thread, a synchronous binder call, or runBlocking on the main thread. Play Console's Android vitals reports ANR rates, and the stack traces show what the main thread was waiting on.

Catching it early

StrictMode can flag disk and network access on the main thread during development:

1if (BuildConfig.DEBUG) {2    StrictMode.setThreadPolicy(3        StrictMode.ThreadPolicy.Builder().detectDiskReads().detectDiskWrites().detectNetwork().penaltyLog().build()4    )5}