When the user presses the power button, it loads the bootloader from a predefined location in ROM to RAM and executes it.

2. Bootloader

This is a small program that loads before kernel. It primarily loads the kernel and executes it.

3. Linux Kernel

When the kernel starts, it performs the initial setup, including memory management, drivers (including the binder driver), cache, scheduling, etc. Once the kernel is loaded and the setup is complete, it starts the init process.

4. Init Process

This is the first user-space process started by Android.

• It creates and mounts file directories required for startup, such as /dev and /proc.
• It initializes system properties.
• It starts native services like ServiceManager and zygote.

This process parses and executes the init.rc script. The implementation of init can be found at system/core/init and the init.rc script can be found at system/core/rootdir/.

5. Zygote

This is the base/template process that gets forked every time a new application is launched.

• It preloads common libraries, resources (eg. Java classes, Android framework classes). Hence, when an application needs to be launched, it will not be starting from scratch.
• It loads the VM (Virtual Machine), where the application's java bytecode will be executed.
• Zygote starts the system server process.

At this time, the boot animation will be visible.

Note: After initialization, Zygote will just wait for AMS (Activity Manager Service) to request start of a new process. When it receives such request, it will fork itself and create to new process.

6. System Server

The system server starts all the SystemServices (e.g. PMS, AMS etc.). It also creates and starts the binder thread pool. This is implemented in frameworks/base/services/java/com/android/server/SystemServer.java

7. Launcher, SystemUI

SystemUI and Launcher are core application in android launcher during boot time. SystemUI is responsible for various core UI components like notifications, the lock screen, the status bar, and the navigation bar. The Launcher is the activity that is base of all the activities, the user can view and launch other applications from the launcher.

The above flow can be summarized in the following diagram:

In subsequent posts, we will dive deeper into the milestones shown above.

The HandlerThread class combines these concepts, simplifying the acquisition of Looper and Handler objects. In this article, we'll explore the implementation of HandlerThread referencing some AOSP code examples.

Internals of HandlerThread

HandlerThread extends the Thread class, providing additional functionality for initializing a Looper and Handler for the associated thread.

Here's the class definition:

/**
 * A {@link Thread} that has a {@link Looper}.
 * The {@link Looper} can then be used to create {@link Handler}s.
 * <p>
 * Note that just like with a regular {@link Thread}, {@link #start()} must still be called.
 */
public class HandlerThread extends Thread {
    // SajalRG: Implementation details...
}

UML class diagram of HandlerThread is shown below:

As demonstrated, HandlerThread essentially functions as a regular Java thread with added capabilities for constructing Looper and providing access to the Looper and Handler instances.

Recap: Construction of Looper

Examining the run() method of HandlerThread, we observe the process of Looper initialization, as discussed in first article of this series.

Looper.prepare() will create a new instance and can be called only once inside a Thread. Looper.loop() waits for message to appear in MessageQueue and process them. For detailed information and innerworking of this, I suggest to read this article.

    @Override
    public void run() {
        mTid = Process.myTid();
        Looper.prepare();
        synchronized (this) {
            mLooper = Looper.myLooper();
            notifyAll();
        }
        Process.setThreadPriority(mPriority);
        onLooperPrepared();
        Looper.loop();
        mTid = -1;
    }

Uses of HandlerThread

Now that we understand what HandlerThread is and how it operates, let's explore its practical utility.

Example1: Setting's App - WifiDialogActivity.java

In this example, HandlerThread is used to obtain a Handler object for the underlying Thread. View Full Code Here.

        if (mIsWifiTrackerLib) {
            // SajalRG: construct new HandlerThread
            mWorkerThread = new HandlerThread(
                    TAG + "{" + Integer.toHexString(System.identityHashCode(this)) + "}",
                    Process.THREAD_PRIORITY_BACKGROUND);
            mWorkerThread.start(); /* SajalRG: actually starts the thread */
            // SajalRG: other code removed for simplicity
            mNetworkDetailsTracker = FeatureFactory.getFactory(this)
                    .getWifiTrackerLibProvider()
                    .createNetworkDetailsTracker(
                            getLifecycle(),
                            this,
                            new Handler(Looper.getMainLooper()), /* SajalRG: passing handler for main looper */
                            mWorkerThread.getThreadHandler(), /* SajalRG: passing handler for the new thread */
                            elapsedRealtimeClock,
                            MAX_SCAN_AGE_MILLIS,
                            SCAN_INTERVAL_MILLIS,
                            mIntent.getStringExtra(KEY_CHOSEN_WIFIENTRY_KEY));
        }

Example 2: Camera2 App - CaptureModule.java

Here, HandlerThread is utilized to acquire a Looper for creating a new Handler object.View Full Code Here.

    @Override
    public void init(CameraActivity activity, boolean isSecureCamera, boolean isCaptureIntent) {
        // SajalRG: other code removed for simplicity
        HandlerThread thread = new HandlerThread("CaptureModule.mCameraHandler");
        thread.start(); /* Thread started */
        /* Create new Handler using looper from handler thread */
        mCameraHandler = new Handler(thread.getLooper());
        // SajalRG: other code removed for simplicity
}

Conclusion

HandlerThread simplifies the creation of a Looper, which otherwise would require manually extending Thread class and overloading the run() method with similar implementation. Understanding the functionality of HandlerThread equips us to leverage its benefits in our projects effectively.

In the next article, we'll address potential memory leak issues with Handler and how to mitigate them.

If you find these articles helpful, please consider liking or commenting to support future content. If you have any questions or topics you'd like covered, feel free to leave a comment below.

Recap of How to Use Handler

Handler can be utilized in two main ways:

1. Passing Runnable: Adding or posting operation to be executed directly inside the thread from another thread. This is accomplished using the post() method of Handler.

2. Sending Message: Sending a message about an operation that needs to be done inside the thread from another thread. This involves a combination of the sendMessage() and handleMessage() methods of Handler.

   While we coverted the post() method extensively in part3, here we will delve into the sendMessage() and handleMessage() methods of the Handler.

When to use sendMessage()

As the name suggests, sendMessage() is used to send a Message object to a Handler and handleMessage() will perform certain operation on the received Message. The two methods, sendMessage() and handleMessage(), must always be used in conjunction. If you usesendMessage() to send a Message to a Handler, the Handler must also implement its handleMessage() to process that message.

Unlike post(), which is suitable for executing a block of code, sendMessage() is used for reusable pieces of code that need to be handled frequently within your thread. For example, when multiple parts of your code needs to save documents, you can use sendMessage() to organize your code more efficiently. All the logic related to file operations will be handled separately, enabling reuse, concurrency, separation of concerns, and synchronous access to the file I/O operations. By passing the path as an argument, the same code can be utilized for multiple other documents, further enhancing its flexibility and maintainability.

Note: In terms of synchronicity, The sendMessage() call itself is asynchronous, non-blocking and can be executed from any thread. The handleMessage() method associated with it will always be invoked synchronously and will run on the same thread that the Handler operates on.

Internals of sendMessage()

Internally both post() and sendMessage() work similarly. The difference lies in how they are handled as seen above. Typically, post() is used for running a one-off block of code in another thread (e.g., updating the UI), and sendMessage() is used for operations that need to be repeated. However, there is no strict rule in the language construct, and it largely depends on your use case and programming style.

To reiterate, here's an excerpt from the Android documentation of Handler

The post versions allow you to enqueue Runnable objects to be called by the message queue when they are received; the sendMessage versions allow you to enqueue a Message object containing a bundle of data that will be processed by the Handler's handleMessage(Message) method (requiring that you implement a subclass of Handler).

Similar to post(), sendMessage() also calls sendMessageDelayed() function to add the Message to the MessageQueue (refer to part 3 for the detailed flow of post()). The only difference lies in the dispatchMessage method which calls handleMessage() instead.

    // SajalRG: adds message to the queue, called from any thread
    public final boolean sendMessage(@NonNull Message msg) {
        return sendMessageDelayed(msg, 0);
    }

    /**
     * Handle system messages here.
     */
   // SajalRG: executed from Looper.loop() inside the thread represented by handler
    public void dispatchMessage(@NonNull Message msg) {
        if (msg.callback != null) {
            handleCallback(msg);
        } else {
            if (mCallback != null) {
                if (mCallback.handleMessage(msg)) {
                    return;
                }
            }
            handleMessage(msg);
        }
    }

Example from AOSP SystemUI

Let's examine an example from AOSP on how this pair can be utilized. We will take a look at the CommandQueue class.

Note: Our objective here is not to delve into the intricacies of the CommandQueue class itself. Instead, we aim to focus solely on how it leverages the sendMessage() and handleMessage() methods. This approach provides insight into real-world usage in larger projects, offering a practical understanding rather than relying on contrived examples.

/**
 * This class takes the functions from IStatusBar that come in on
 * binder pool threads and posts messages to get them onto the main
 * thread, and ...
 */
public class CommandQueue extends IStatusBar.Stub implements
        CallbackController<Callbacks> {

In this example, CommandQueue also extends the IStatusBar.stub(), which we can ignore for now but it could be a topic for furture articles on Binder and AIDL. CallbackController is an interface which the CommandQueue implements, but we won't explore it further in this post.

For our purpose, CommandQueue has some methods that are called from other threads, referred to as binder pool threads, and it will post the messages onto the main thread.

Understanding CommandQueue

If you view the CommandQueue class from this link, you might notice that there is no sendMessage() call in the class, even though we are using this as an example for sendMessage().

To understand this, let's look at Message class. We partially covered the Message class in part 2, please review if you haven't already. Now, let's introduce method sendToTarget class which is used here. It internally calls the sendMessage() for us. Both approaches are okay.

    /**
     * Sends this Message to the Handler specified by {@link #getTarget}.
     * Throws a null pointer exception if this field has not been set.
     */
    public void sendToTarget() {
        target.sendMessage(this);
    }

Also, instead of using Message.obtain() to create new Message, as we saw in part3, Handler.obtainMessage() is used here, which internally does the same. Below is the excerpt from the Handler class listing all other possible ways to obtain Message.

    @NonNull
    public final Message obtainMessage() {
        return Message.obtain(this);
    }

    /**
     * Same as {@link #obtainMessage()}, except that it also sets the what member of the returned Message.
     * 
     * @param what Value to assign to the returned Message.what field.
     * @return A Message from the global message pool.
     */
    @NonNull
    public final Message obtainMessage(int what) {
        return Message.obtain(this, what);
    }

    /**
     * 
     * Same as {@link #obtainMessage()}, except that it also sets the what and obj members 
     * of the returned Message.
     * 
     * @param what Value to assign to the returned Message.what field.
     * @param obj Value to assign to the returned Message.obj field.
     * @return A Message from the global message pool.
     */
    @NonNull
    public final Message obtainMessage(int what, @Nullable Object obj) {
        return Message.obtain(this, what, obj);
    }

    /**
     * 
     * Same as {@link #obtainMessage()}, except that it also sets the what, arg1 and arg2 members of the returned
     * Message.
     * @param what Value to assign to the returned Message.what field.
     * @param arg1 Value to assign to the returned Message.arg1 field.
     * @param arg2 Value to assign to the returned Message.arg2 field.
     * @return A Message from the global message pool.
     */
    @NonNull
    public final Message obtainMessage(int what, int arg1, int arg2) {
        return Message.obtain(this, what, arg1, arg2);
    }

    /**
     * 
     * Same as {@link #obtainMessage()}, except that it also sets the what, obj, arg1,and arg2 values on the 
     * returned Message.
     * @param what Value to assign to the returned Message.what field.
     * @param arg1 Value to assign to the returned Message.arg1 field.
     * @param arg2 Value to assign to the returned Message.arg2 field.
     * @param obj Value to assign to the returned Message.obj field.
     * @return A Message from the global message pool.
     */
    @NonNull
    public final Message obtainMessage(int what, int arg1, int arg2, @Nullable Object obj) {
        return Message.obtain(this, what, arg1, arg2, obj);
    }

In above code snippet, different signature which allows us to pass additional information to the Message are also listed. Here, what is primarily used in handleMessage() identify which operation to perform.

Message flow in CommandQueue

Let's explore the addQsTile method to explore the message flow. First, the method is called from the binder thread.

    // SajalRG: create new handler using the main looper
    private Handler mHandler = new H(Looper.getMainLooper());
    @Override
    public void addQsTile(ComponentName tile) {
        synchronized (mLock) {
            // SajalRG: get message object and send the message
            mHandler.obtainMessage(MSG_ADD_QS_TILE, tile).sendToTarget();
        }
    }

Then, it is handled inside the Handler

    private final class H extends Handler {
        private H(Looper l) {
            super(l);
        }
        // SajalRG: handleMessage is called in conjunction to the sendMessage
        public void handleMessage(Message msg) {
            final int what = msg.what & MSG_MASK;
            // SajalRG: what is used to identify which operation to execute
            switch (what) {
                // SajalRG: other cases
                case MSG_ADD_QS_TILE:
                    // SajalRG: actual operation happening inside the main thread
                    for (int i = 0; i < mCallbacks.size(); i++) {
                        mCallbacks.get(i).addQsTile((ComponentName) msg.obj);
                    }
                    break;
                // SajalRG: other cases
            }
        }
    }

What's next

This post concludes our introduction to Handler, Looper and Thread. I hope you have a clearer understanding of the subject and how they are interconnected at a high level. I'd still like to continue this series addressing some misconceptions I'd come across and answer some frequently asked questions related to this topic. If you have any specific topics or query you'd like me to cover, please feel free to leave a comment.

Your support serves as great encouragement for me to continue creating and sharing content.

In this article, we will explore deeper into the post() method of Handler, with an example. By the end of this article, you would have a clear understanding of how the post() method executes your code in a different thread.

How to use Handler

There are two main way Handler can be used in programming:

1. Adding or posting operation to be executed directly inside the thread from another thread. This flow is invoked by the post() method of Handler.
2. Sending a message about the operation which needs to be done inside the thread from another thread. This flow is invoked by a combination of thesendMessage() and handleMessage() methods of Handler.

When to use post()

The post() method is particularly useful when you want to quickly run a block of code in another thread. For example, if you are running some computationally intensive operation in a background thread but want to post updates to the UI, then you can use a Handler attached to the MainThread for same.

// Example code demonstrating the usage of post() method
public class ThreadWithLongRunningOperation extends Thread {

    @Override
    public void run() {
        // Some long running operation

        // Post intermediate progress to UI
        Handler mainThreadHandler = new Handler(Looper.getMainLooper());
        mainThreadHandler.post(new Runnable() {
            @Override
            public void run() {
                // update UI
            }
        });

        // Continue operation

        // Update UI to show completion (here, runnable is posted using lambda)
        mainThreadHandler.post(() -> {
            // Update UI
        });
    }
}

Inner working of post()

The signature of the post method is

public final boolean post (Runnable r)

From part 2, we know that Handler is used to interact with the Message loop, and Looper only operates on the Message object. So, post() will first convert the Runnable to a Message and add it to the queue as shown below AOSP code snippet of Handler.java:

    // Method to convert Runnable to Message
    private static Message getPostMessage(Runnable r) {
        Message m = Message.obtain();
        m.callback = r;
        return m;
    }

    /**
     * Causes the Runnable r to be added to the message queue.
     * The runnable will be run on the thread to which this handler is 
     * attached.
     */
    public final boolean post(@NonNull Runnable r) {
       return  sendMessageDelayed(getPostMessage(r), 0);
    }

    /**
     * Enqueue a message into the message queue after all pending messages
     * before (current time + delayMillis). You will receive it in
     * {@link #handleMessage}, in the thread attached to this handler.
     */
    public final boolean sendMessageDelayed(@NonNull Message msg, long delayMillis) {
        if (delayMillis < 0) {
            delayMillis = 0;
        }
        return sendMessageAtTime(msg, SystemClock.uptimeMillis() + delayMillis);
    }

    /**
     * Enqueue a message into the message queue after all pending messages
     * before the absolute time (in milliseconds) <var>uptimeMillis</var>.
     * <b>The time-base is {@link android.os.SystemClock#uptimeMillis}.</b>
     * Time spent in deep sleep will add an additional delay to execution.
     * You will receive it in {@link #handleMessage}, in the thread attached
     * to this handler.
     */
    public boolean sendMessageAtTime(@NonNull Message msg, long uptimeMillis) {
        MessageQueue queue = mQueue;
        if (queue == null) {
            RuntimeException e = new RuntimeException(
                    this + " sendMessageAtTime() called with no mQueue");
            Log.w("Looper", e.getMessage(), e);
            return false;
        }
        return enqueueMessage(queue, msg, uptimeMillis);
    }

Note: You can also use Handler to post block of code to execute on same or another thread with some delay using postDelayed method. If you want to execute the Runnable after some time instead of immediately you can replace post with postDelayed. Using postDelayed will call sendMessageDelayed method with the delay provided in the parameter instead of 0 as shown above.

Finally, the runnable is executed inside dispatchMessage() from the loop() method we saw in part2.

public void dispatchMessage(@NonNull Message msg) {
    if (msg.callback != null) {
        handleCallback(msg);
    } else {
        // Handle other types of messages
    }
}

private static void handleCallback(Message message) {
    message.callback.run();
}

Adding these new pieces to our sequence diagram from part 2, results in below diagram

Example

Now, let us look at an example where we will use the post() method. Here, we will post() the progress of some long running operation in the main thread which will update the UI. This is similar to how we used to update UI inside AsyncTask's onProgressUpdate. As AsyncTask is now deprecated, this is a suitable alternative.

First, let us update the ThreadWithLongRunningOperation class as below

public class ThreadWithLongRunningOperation extends Thread {

    private final Consumer<Integer> mOnThreadProgressConsumer;

    public ThreadWithLongRunningOperation(Consumer<Integer> onThreadProgressConsumer) {
        this.mOnThreadProgressConsumer = onThreadProgressConsumer;
    }

    @Override
    public void run() {
        // Dummy sleep value to show work is happening
        final long SLEEP_TIME_MS = 1000;

        // Create a handler using the Main thread looper
        Handler mainThreadHandler = new Handler(Looper.getMainLooper());

        // Post to the main handler; this will run the Runnable code block in UI thread
        mainThreadHandler.post(() -> mOnThreadProgressConsumer.accept(0));

        // Some long-running operation; using sleep to simulate the same
        trySleep(SLEEP_TIME_MS);

        // Post intermediate progress to UI
        mainThreadHandler.post(() -> mOnThreadProgressConsumer.accept(50));

        // Continue operation; using sleep to simulate the same
        trySleep(SLEEP_TIME_MS);

        // Update UI to show completion
        mainThreadHandler.post(() -> mOnThreadProgressConsumer.accept(100));
    }

    private void trySleep(long millis) {
        try {
            sleep(millis);
        } catch (InterruptedException e) {
            // do nothing
        }
    }
}

Note: If you want to learn about the Consumer interface, I have posted an article here.

In the activity_main.xml layout we will use the TextView to show the progress:

    <TextView
        android:id="@+id/counter_tv"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:text="0"
        app:layout_constraintBottom_toBottomOf="parent"
        app:layout_constraintEnd_toEndOf="parent"
        app:layout_constraintStart_toStartOf="parent"
        app:layout_constraintTop_toTopOf="parent" />

Finally, in our MainActivity.java, we will start the Thread and consume the update as follows:

public class MainActivity extends AppCompatActivity {

    TextView mCounterTextView;

    @Override
    protected void onCreate(@Nullable Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);

        mCounterTextView = findViewById(R.id.counter_tv);
    }

    @Override
    protected void onResume() {
        super.onResume();
        ThreadWithLongRunningOperation threadWithLongRunningOperation
                = new ThreadWithLongRunningOperation(
                        (progress) -> mCounterTextView.setText(String.valueOf(progress))
        );
        threadWithLongRunningOperation.start();
    }
}

Example explanation

The provided code features a custom thread, ThreadWithLongRunningOperation, which executes a simulated long-running operation and communicates progress updates to the UI thread through a Handler. The Handler, associated with the main thread's Looper, posts UI updates using the post() method to be executed inside the UIThread.

In the MainActivity, an instance of this custom thread is created and started in the onResume method, with progress updates displayed in a TextView. The Handler ensures proper communication between the background thread and the UI thread, allowing smooth progress updates in response to the long-running operation.

Conclusion

In this article, we examined how Message gets added to the MessageQueue inside the Handler class. We explored how Runnable objects are converted to Message and saw an example of using the post() method to update the UI thread from another background thread.

In the next article, we will continue our exploration of the Handler class and delve into the usage of the sendMessage() and handleMessage() methods.

Stay tuned for more insights into effective handler usage in Android development!

Construction of Handler

Just as Looper in Android is linked to a single thread, it's important to note that a Handler is similarly tied to a single Looper. However, unlike the Looper you can create multiple objects of the Handler class within the same thread.

Application developers have two constructors at their disposal for creating a new Handler class:

public Handler (Looper looper)
public Handler (Looper looper, Handler.Callback callback)

Note: Two additional public constructors, public Handler() and public Handler(Handler.Callback callback), are now deprecated. If you encounter these constructors or choose to use them for some reason, be aware that they internally use the looper obtained via the Looper.myLooper() method.

Here is the actual constructor of the handler, not accessible to app developers. I'm presenting it here to shed light on the inner workings of the handler:

public Handler(@NonNull Looper looper, @Nullable Callback callback, boolean async, boolean shared) {
    mLooper = looper;
    mQueue = looper.mQueue;
    mCallback = callback;
    mAsynchronous = async;
    mIsShared = shared;
}

Note: This multipart article won't cover the details of mAsynchronous and mIsShared.

Message and Callback classes

Before comprehending the role of the Handler, let us examine the definitions of the Handler.Callback and Message classes

1. Handler.Callback

The Callback interface is defined inside Handler class as follows:

public interface Callback {
    /**
    * @param msg A {@link android.os.Message Message} object
    * @return True if no further handling is desired
    */
    boolean handleMessage(@NonNull Message msg);
}

2. Message

The Message class has various fields and methods, but for our use case we'll focus on a subset of those:

public final class Message implements Parcelable {
    /**
     * User-defined message code so that the recipient can identify
     * what this message is about. Each {@link Handler} has its own name-space
     * for message codes, so you do not need to worry about yours conflicting
     * with other handlers.
     */
    public int what;

    /**
     * arg1 and arg2 are lower-cost alternatives to using
     * {@link #setData(Bundle) setData()} if you only need to store a
     * few integer values.
     */
    public int arg1;

    /**
     * arg1 and arg2 are lower-cost alternatives to using
     * {@link #setData(Bundle) setData()} if you only need to store a
     * few integer values.
     */
    public int arg2;

    /**
     * An arbitrary object to send to the recipient.  When using
     * {@link Messenger} to send the message across processes this can only
     * be non-null if it contains a Parcelable of a framework class (not one
     * implemented by the application).   For other data transfer use
     * {@link #setData}.
     *
     * <p>Note that Parcelable objects here are not supported prior to
     * the {@link android.os.Build.VERSION_CODES#FROYO} release.
     */
    public Object obj;

    @UnsupportedAppUsage
    /*package*/ Handler target;

    @UnsupportedAppUsage
    /*package*/ Runnable callback;
}

Relationship between Handler, Message and Looper

Handler is used to interact with the Message loop i.e. Looper.loop().

In part 1, we delved into a high-level understanding of the Looper.loop() method. Now, let's take a close look at the implementation of this method.

public static void loop() {
    final Looper me = myLooper();
    if (me == null) {
        throw new RuntimeException("No Looper; Looper.prepare() wasn't called on this thread.");
    }
    /* << unrelated code removed for comprehension >> */
    for (;;) {
        if (!loopOnce(me, ident, thresholdOverride)) {
            return;
        }
    }
}

private static boolean loopOnce(final Looper me, final long ident, final int thresholdOverride) {
    Message msg = me.mQueue.next(); // might block
    if (msg == null) {
        // No message indicates that the message queue is quitting.
        return false;
    }
    /* << unrelated code removed for comprehension >> */
    try {
        msg.target.dispatchMessage(msg);
        if (observer != null) {
            observer.messageDispatched(token, msg);
        }
        dispatchEnd = needEndTime ? SystemClock.uptimeMillis() : 0;
    } catch (Exception exception) {
        /* << unrelated code removed for comprehension >> */
        throw exception;
    }
    /* << unrelated code removed for comprehension >> */
}

Note: I've included only the essential code for our comprehension, but you can refer to the complete code here.

Here, msg.target has reference to the instance of the Handler class and the Looper calls the dispatchMessage() method of the Handler class in each loop. This occurs inside the Thread where the Looper is looping. Same can be visualised in below sequence diagram

By now, we've covered Looper, Handler, and the Message class and have an understanding of the role of the MessageQueue.

In the upcoming article, we will consolidate our knowledge gained so far and apply it in real-world scenarios to effectively utilize the Handler class. Additionally, we will closely examine the dispatchMessage() method to deepen our understanding of its role in the overall process.

A Thread can be seen as a lightweight process, enabling the execution of multiple operations in parallel. However, our focus in this article will shift towards Looper, Handler classes in Android and understanding their relationship with Thread. More information on Thread can be found here.

In Android, your application/activity will inherently possess at least one Thread, known as the MainThread. Android generally prefers abstracting the underlying thread and instead encourages the use of android classes like Handler.

A Looper in Android is associated with a single thread. If you've worked in Android, you might have come across methods like Looper.getMainLooper() or Looper.myLooper(). In this article, we will deep dive into those and try to understand what they do. Later, we will link this concept to Handler and MessageQueue.

Construction of a Looper.

As the Looper constructor is private, the only way to create a Looper is by invoking Looper.prepare().

However, if you try to call this inside you activity like below it will crash your application.

@Override
protected void onResume() {
    super.onResume();
    // This will crash with Runtime exception "Only one Looper may be created per thread"
    Looper.prepare();
}

When examining the logcat logs for the crash, the stack trace will appear as follows:

Caused by: java.lang.RuntimeException: Only one Looper may be created per thread
    at android.os.Looper.prepare(Looper.java:109)
    at android.os.Looper.prepare(Looper.java:104)
    at com.sajalrg.looperhandlerandroid.MainActivity.onResume(MainActivity.java:20)

The crash is attributed to the constraint of allowing only one Looper object per thread. As previously explained, your Activity operates on the Thread known as the MainThread, which already has an associated Looper.

Hence, to create a new Looper, you need to define a new Thread. Let's do that.

public class MyLooperThread extends Thread {

    @Override
    public void run() {
        // calling Looper.prepare() inside thread once will not crash and creates new Looper object
        Looper.prepare();
    }
}

Now, you can create new Looper instance by starting the Thread.

@Override
protected void onResume() {
    super.onResume();
    MyLooperThread myLooperThread = new MyLooperThread();
    // this will start new thread and call the run() method of thread
    myLooperThread.start();
}

Please be aware not to conflate myLooperThread.start() with myLooperThread.run(). In this context, invoking the run() method will not initiate the thread; instead, it merely executes the run() method within the same thread. To commence a new thread and internally trigger the run() method within the new thread, it is imperative to use the myLooperThread.start() method.

To obtain the existing Looper instance for a specific thread, you can call the Looper.myLooper() method in the thread. This function returns the Looper instance associated with the thread, if one exists. To obtain an instance of the Looper for the MainThread, you can call Looper.getMainLooper() from any thread, and it will consistently return the Looper associated with the MainThread.

Working with Looper

Although we have successfully created a Looper object, our class currently serves no significant purpose. To understand its utility, let's examine another method, Looper.loop().

As the name suggests, this method runs an infinite loop, implying that your thread will never exit. Let's use it in our MyLooperThread class.

public class MyLooperThread extends Thread {

    public MyLooperThread() {
        // lets give our thread name so we can identify it in ps output
        super("MyLooperThread");
    }

    @Override
    public void run() {
        // calling Looper.prepare() inside thread once will not crash and creates new Looper object
        Looper.prepare();
        Log.d("MyLooperThread ", "run(): after Looper.prepare()");
        Looper.loop();
        Log.d("MyLooperThread ", "run(): after Looper.loop()");
    }
}

Upon running the code, you'll notice that "run(): after Looper.loop()" is never printed. You can also confirm that your thread is running by executing below shell command

adb shell ps -T | grep "MyLooperThread"

It's crucial to note that executing the above shell command without the inclusion of Looper.loop() will result in no output. This is because the thread would have terminated after the invocation of Looper.prepare().

Now, before taking a closer look at Looper and the loop(), let's examine the constructor of Looper.

    private Looper(boolean quitAllowed) {
        mQueue = new MessageQueue(quitAllowed);
        mThread = Thread.currentThread();
    }

The Looper constructor comprises a MessageQueue. As the name implies, the MessageQueue is a queue of Messages. We will dig deeper into MessageQueue and Messages in subsequent articles. For now, let's continue examination of the loop() method.

The loop() method iterates indefinitely through the MessageQueue, performing operations if any messages are present. This perpetual execution takes place within the same thread where the Looper is actively looping.

Although we haven't delved deeply into Message yet, the primary focus of this post was to provide an introduction to the Looper. I assume you now have a high-level understanding of what the Looper is, how it is created, and its usage. If you still have any lingering questions or uncertainties regarding the Looper, feel free to ask in the comments.

In the subsequent post, we will explore Message and Handler in greater detail. Stay tuned for a more in-depth discussion on these concepts.