In the previous parts of this series, we explored what processes are, how they are launched, and the hierarchy Android uses to manage them. Now it's time to look inside a process and understand what actually happens when your app starts running. inside This is where things get very practical. One of the best ways to understand a foundational concept is to build a simplified version of it yourself — so that's exactly what we'll do here with the Looper and the MessageQueue. Looper MessageQueue When an app launches, it runs in its own process container. Every process hosts at least one thread: the main thread. On Android, the main thread carries a lot of responsibility: main thread Drawing and updating the UI
Handling touch and keyboard input events
Dispatching framework callbacks
Invoking Activity lifecycle callbacks (onCreate, onStart, onResume, etc.)
Invoking BroadcastReceiver.onReceive()
Running Service callbacks (normal services run on the main thread by default) Drawing and updating the UI Handling touch and keyboard input events Dispatching framework callbacks Invoking Activity lifecycle callbacks (onCreate, onStart, onResume, etc.) onCreate onStart onResume Invoking BroadcastReceiver.onReceive() BroadcastReceiver.onReceive() Running Service callbacks (normal services run on the main thread by default) But two concepts unique to Android are introduced on top of this thread that most developers have seen referenced without fully understanding them: Looper
MessageQueue Looper Looper MessageQueue MessageQueue Let's break both down. Why Does a Thread Need a Looper? In standard software development, a thread has a simple lifecycle: it starts, executes its code, and exits. In Kotlin, this looks like: thread {
    println("Hello World!")
} thread {
    println("Hello World!")
} The thread launches, prints the message, and terminates. That's normal and expected behavior. Now apply that same logic to the main thread of an Android app. Your Activity launches. onCreate() fires. onStart() fires. onResume() fires. Your ViewModel initializes. The UI renders. And then... the main thread has nothing left to do. Under normal thread behavior, it would simply exit. Activity onCreate() onStart() onResume() But that's obviously not what happens. The user could tap the screen at any moment. A keyboard event could arrive. A background thread could finish a network request and need to post a UI update. The main thread needs to stay alive and ready, not just for what it's doing right now, but for everything that might arrive in the future. ready The Looper is what keeps the thread alive. The Looper is what keeps the thread alive. Every thread can optionally have one Looper. The Looper does one thing: it runs an infinite loop. When there's work to do, the thread processes it. When there's nothing to do, the Looper blocks, it waits, without burning CPU cycles, for the next instruction to arrive. The moment something new enters the queue, the loop resumes and processes it, then blocks again. blocks This is why the main thread never dies for as long as your app is running. The MessageQueue The MessageQueue is the data structure that feeds the Looper. It's a classic First In, First Out (FIFO) queue, just like a real-world queue at a ticket counter. The first event to arrive is the first event to be processed. MessageQueue First In, First Out (FIFO) Here's a concrete example of how this plays out: The user taps the screen → a touch event enters the queue
Milliseconds later, a keyboard event fires → it enters the queue behind the touch event
The Looper processes the touch event first, then the keyboard event The user taps the screen → a touch event enters the queue Milliseconds later, a keyboard event fires → it enters the queue behind the touch event The Looper processes the touch event first, then the keyboard event All these events are packaged as Messages and queued up for sequential processing on the main thread. Messages Android exposes the Looper system through a simple API: Looper.getMainLooper()  // The Looper of the main thread
Looper.myLooper()       // The Looper of the current thread
Looper.myQueue()        // The MessageQueue of the current Looper Looper.getMainLooper()  // The Looper of the main thread
Looper.myLooper()       // The Looper of the current thread
Looper.myQueue()        // The MessageQueue of the current Looper Building Our Own Looper The best way to understand this is to implement a simplified version. The real Android Looper implementation is significantly more complex, but the core idea maps directly onto what we're about to build. Looper import java.util.concurrent.LinkedBlockingQueue
import kotlin.concurrent.thread

class MyLooper {

    // The thread this Looper will run on
    private var thread: Thread? = null

    // The queue of events to be processed
    // (Runnable is simply something that can be executed)
    private val messageQueue = LinkedBlockingQueue<Runnable>()

    // Add an event to the queue
    fun enqueue(runnable: Runnable) {
        if (thread == null) {
            createLooperThread()
        }
        messageQueue.offer(runnable)
    }

    // Initialize the looper thread the first time something is enqueued.
    // The thread stays alive by blocking on messageQueue.take(),
    // which waits until a new message is available.
    // We wrap everything in a try-catch because quit() interrupts the thread,
    // which causes take() to throw an InterruptedException.
    private fun createLooperThread() {
        thread = thread ?: thread {
            try {
                while (true) { // This is our Looper
                    val message = messageQueue.take() // Blocks when queue is empty
                    message.run()
                }
            } catch (e: InterruptedException) {
                return@thread
            }
        }
    }

    // Stop the looper and clean up the thread
    fun quit() {
        thread?.interrupt()
        thread = null
    }
} import java.util.concurrent.LinkedBlockingQueue
import kotlin.concurrent.thread

class MyLooper {

    // The thread this Looper will run on
    private var thread: Thread? = null

    // The queue of events to be processed
    // (Runnable is simply something that can be executed)
    private val messageQueue = LinkedBlockingQueue<Runnable>()

    // Add an event to the queue
    fun enqueue(runnable: Runnable) {
        if (thread == null) {
            createLooperThread()
        }
        messageQueue.offer(runnable)
    }

    // Initialize the looper thread the first time something is enqueued.
    // The thread stays alive by blocking on messageQueue.take(),
    // which waits until a new message is available.
    // We wrap everything in a try-catch because quit() interrupts the thread,
    // which causes take() to throw an InterruptedException.
    private fun createLooperThread() {
        thread = thread ?: thread {
            try {
                while (true) { // This is our Looper
                    val message = messageQueue.take() // Blocks when queue is empty
                    message.run()
                }
            } catch (e: InterruptedException) {
                return@thread
            }
        }
    }

    // Stop the looper and clean up the thread
    fun quit() {
        thread?.interrupt()
        thread = null
    }
} A few things to notice here: LinkedBlockingQueue.take() is the key to the whole thing. When the queue is empty, take() blocks — it suspends execution on that thread without spinning or wasting CPU. The moment a new Runnable is added via offer(), take() unblocks and the loop continues. This is the exact mechanism the Android Looper uses to keep a thread alive while idle. LinkedBlockingQueue.take() take() blocks Runnable offer() take() The while (true) loop is the Looper itself, it keeps running forever until quit() is called, which interrupts the thread and breaks out of the loop via the InterruptedException. while (true) quit() InterruptedException Using Our Looper Here's a practical demonstration using our custom MyLooper inside an Activity: MyLooper Activity class MainActivity : ComponentActivity() {

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        enableEdgeToEdge()

        val myLooper = MyLooper()

        // Enqueue 5 tasks immediately
        repeat(5) {
            myLooper.enqueue(sampleRunnable(it))
        }

        // After 10 seconds of idle, enqueue one more task
        lifecycleScope.launch {
            delay(10_000L)
            myLooper.enqueue(sampleRunnable(5))
        }

        setContent {
            AndroidInternalsTheme {}
        }
    }

    // A sample Runnable that simulates a task taking 1 second to complete
    private fun sampleRunnable(index: Int): Runnable {
        return Runnable {
            println("Runnable $index started.")
            Thread.sleep(1000L)
            println("Runnable $index finished.")
        }
    }
} class MainActivity : ComponentActivity() {

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        enableEdgeToEdge()

        val myLooper = MyLooper()

        // Enqueue 5 tasks immediately
        repeat(5) {
            myLooper.enqueue(sampleRunnable(it))
        }

        // After 10 seconds of idle, enqueue one more task
        lifecycleScope.launch {
            delay(10_000L)
            myLooper.enqueue(sampleRunnable(5))
        }

        setContent {
            AndroidInternalsTheme {}
        }
    }

    // A sample Runnable that simulates a task taking 1 second to complete
    private fun sampleRunnable(index: Int): Runnable {
        return Runnable {
            println("Runnable $index started.")
            Thread.sleep(1000L)
            println("Runnable $index finished.")
        }
    }
} When you run this, you'll see: Runnables 0 through 4 execute one after another, each taking one second
After a 10-second gap (simulating an idle thread), Runnable 5 arrives and executes Runnables 0 through 4 execute one after another, each taking one second After a 10-second gap (simulating an idle thread), Runnable 5 arrives and executes This is exactly what the main thread does in your app all day, processing events as they arrive, blocking between them, and never shutting down until the app is killed. The Real-World Consequence: A MessageQueue Bug Understanding the Looper and MessageQueue isn't just theoretical. It directly explains a category of bug that many Android developers have hit without understanding why it happens. Consider a ViewModel with a simple counter and a button that increments it: class MyViewModel {
    private val _counter = MutableStateFlow(0)
    val counter = _counter.asStateFlow()

    fun increment() {
        _counter.update { it + 1 }
    }
} class MyViewModel {
    private val _counter = MutableStateFlow(0)
    val counter = _counter.asStateFlow()

    fun increment() {
        _counter.update { it + 1 }
    }
} And a UI that reads the counter state and prints it on click: val counter by viewModel.counter.collectAsState()

Button(
    onClick = {
        viewModel.increment()
        println("Counter: $counter") // What does this print?
    }
) {
    Text("Counter: $counter")
} val counter by viewModel.counter.collectAsState()

Button(
    onClick = {
        viewModel.increment()
        println("Counter: $counter") // What does this print?
    }
) {
    Text("Counter: $counter")
} You might expect that after calling increment(), the println would show the new value. But it doesn't, it prints the old value. increment() println old Why? Why? Because of the MessageQueue. The onClick callback is processed as a single message in the queue, one loop iteration of the Looper. Within that same iteration, counter still holds the reference it had when the iteration started. The collectAsState() function collects state updates on the Main dispatcher, but that collection happens in a separate loop iteration, a separate message processed later in the queue. By the time the UI shows the new value, the onClick message has already finished. onClick counter collectAsState() separate loop iteration onClick The fix is one line: val counter by viewModel.counter.collectAsState(
    context = Dispatchers.Main.immediate
) val counter by viewModel.counter.collectAsState(
    context = Dispatchers.Main.immediate
) Dispatchers.Main.immediate changes the behavior: if the collector is already running on the main thread, it updates the value immediately within the same call stack rather than posting it as a new message to the queue. The result is that counter reflects the incremented value by the time println runs. Dispatchers.Main.immediate immediately counter println The full corrected implementation: class MainActivity : ComponentActivity() {

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        enableEdgeToEdge()

        val myLooper = MyLooper()

        repeat(5) {
            myLooper.enqueue(sampleRunnable(it))
        }

        lifecycleScope.launch {
            delay(10_000L)
            myLooper.enqueue(sampleRunnable(5))
        }

        val viewModel = MyViewModel()

        setContent {
            AndroidInternalsTheme {
                Scaffold(modifier = Modifier.fillMaxSize()) { innerPadding ->

                    // Dispatchers.Main.immediate ensures the collector updates
                    // synchronously on the same call stack — not as a new queue message
                    val counter by viewModel.counter.collectAsState(
                        context = Dispatchers.Main.immediate
                    )

                    Button(
                        onClick = {
                            viewModel.increment()
                            println("Counter: $counter") // Now prints the correct value
                        },
                        modifier = Modifier
                            .fillMaxSize()
                            .wrapContentSize()
                    ) {
                        Text("Counter: $counter")
                    }
                }
            }
        }
    }

    private fun sampleRunnable(index: Int): Runnable {
        return Runnable {
            println("Runnable $index started.")
            Thread.sleep(1000L)
            println("Runnable $index finished.")
        }
    }
} class MainActivity : ComponentActivity() {

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        enableEdgeToEdge()

        val myLooper = MyLooper()

        repeat(5) {
            myLooper.enqueue(sampleRunnable(it))
        }

        lifecycleScope.launch {
            delay(10_000L)
            myLooper.enqueue(sampleRunnable(5))
        }

        val viewModel = MyViewModel()

        setContent {
            AndroidInternalsTheme {
                Scaffold(modifier = Modifier.fillMaxSize()) { innerPadding ->

                    // Dispatchers.Main.immediate ensures the collector updates
                    // synchronously on the same call stack — not as a new queue message
                    val counter by viewModel.counter.collectAsState(
                        context = Dispatchers.Main.immediate
                    )

                    Button(
                        onClick = {
                            viewModel.increment()
                            println("Counter: $counter") // Now prints the correct value
                        },
                        modifier = Modifier
                            .fillMaxSize()
                            .wrapContentSize()
                    ) {
                        Text("Counter: $counter")
                    }
                }
            }
        }
    }

    private fun sampleRunnable(index: Int): Runnable {
        return Runnable {
            println("Runnable $index started.")
            Thread.sleep(1000L)
            println("Runnable $index finished.")
        }
    }
} Note: This exact class of bug is also the reason the new TextField2 API was introduced in Jetpack Compose. The old TextField suffered from stale state reads within the same message loop iteration — a subtle but frustrating issue caused by this very mechanism. Note: This exact class of bug is also the reason the new TextField2 API was introduced in Jetpack Compose. The old TextField suffered from stale state reads within the same message loop iteration — a subtle but frustrating issue caused by this very mechanism. TextField2 TextField Putting It All Together Here's a mental model that ties everything in this article together: Every interaction your user has with your app, every lifecycle callback, every UI update, all of it flows through this single queue, processed one message at a time on the main thread. The Looper keeps your thread alive. Without it, the main thread would exit as soon as it ran out of immediate work to do. The infinite loop, combined with a blocking queue, is what turns a one-shot thread into a persistent event processor. The Looper keeps your thread alive. The MessageQueue enforces sequential processing. Everything on the main thread happens in order, one message at a time. This is what guarantees UI thread safety, you don't need locks on the main thread because nothing can interrupt a running message. The MessageQueue enforces sequential processing. Dispatchers.Main.immediate matters. When you need a state update to be visible within the same call stack, not deferred to the next queue iteration, this is the dispatcher to reach for. Knowing why it works the way it does makes it much easier to know when to use it. Dispatchers.Main.immediate why when

The is an opinion piece based on the author’s POV and does not necessarily reflect the views of HackerNoon.

This story contains AI-generated text. The author has used AI either for research, to generate outlines, or write the text itself. 

Android OS Architecture, Part 7: Inside the Main Thread, Looper and MessageQueue

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Android OS Architecture, Part 2: How the Android System Fits Together

105 Stories To Learn About Ios App Development

10 Things to check on Android code reviews

10 good rules for bad App

The Noonification: Accelerating Android Application Development With the ADB Idea Plugin (10/12/2022)

11 Tips to Save Time on App Development & Launch Processes

Android OS Architecture, Part 2: How the Android System Fits Together

105 Stories To Learn About Ios App Development

10 Things to check on Android code reviews

10 good rules for bad App

The Noonification: Accelerating Android Application Development With the ADB Idea Plugin (10/12/2022)

11 Tips to Save Time on App Development & Launch Processes

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps