In Part 7, we explored the main thread, the Looper, and the MessageQueue. We saw how the Looper keeps a thread alive by blocking on an infinite loop, and how messages are queued and processed one at a time. If you haven't read that yet, it's worth going through before continuing here. In Part 7 Now we go one level up. Two terms appear constantly whenever you're working with threads, Loopers, and MessageQueues on Android: Handlers and System Services. Neither is particularly complex once you see what they actually are, but both are fundamental enough that misunderstanding them creates confusion across a wide range of Android topics. Handlers System Services Handlers Handlers A Handler is exactly what the name suggests, something that handles the scheduling of a piece of work onto a specific thread. Handler More precisely, a Handler takes a Runnable (a block of code you want to execute) and appends it to the MessageQueue of a specific thread's Looper. That's the entire job. It's a bridge between wherever you are right now and wherever you need your code to run. Runnable Handler(Looper.getMainLooper()).post {
    textView.setText("Hello World!")
} Handler(Looper.getMainLooper()).post {
    textView.setText("Hello World!")
} This is the most common real-world use case. Here's the scenario: You make a network request on a background thread
The response comes back, still on the background thread
You need to update a TextView with the response data
But UI updates on Android can only happen on the main thread You make a network request on a background thread The response comes back, still on the background thread You need to update a TextView with the response data TextView But UI updates on Android can only happen on the main thread only Without a Handler, you're stuck. You're on the wrong thread. The Handler solves this by taking your UI update code and posting it to the main thread's MessageQueue via Looper.getMainLooper(). The main thread's Looper picks it up in its next iteration and executes it safely on the main thread. Looper.getMainLooper() This is why you'll see Handler(Looper.getMainLooper()) referenced in the implementation of things like coroutine dispatchers, View.post(), runOnUiThread(), and many other Android APIs. They're all doing the same thing under the hood, which is posting work to the main thread's MessageQueue via a Handler. Handler(Looper.getMainLooper()) View.post() runOnUiThread() The relationship between these components looks like this: A Handler isn't limited to the main thread either. You can create a Handler for any thread that has a Looper, which is exactly what HandlerThread provides, a background thread with a Looper attached, so you can post work to it via a Handler. This is the foundation that Android's AsyncTask (now deprecated) was built on, and it still powers parts of the framework today. HandlerThread AsyncTask System Services System Services If you've written any Android code at all, you've almost certainly called getSystemService(). Location data, sensor values, clipboard access, vibration, connectivity status, all of it comes through this single function: getSystemService() val locationManager = getSystemService(Context.LOCATION_SERVICE) as LocationManager
val sensorManager = getSystemService(Context.SENSOR_SERVICE) as SensorManager
val connectivityManager = getSystemService(Context.CONNECTIVITY_SERVICE) as ConnectivityManager val locationManager = getSystemService(Context.LOCATION_SERVICE) as LocationManager
val sensorManager = getSystemService(Context.SENSOR_SERVICE) as SensorManager
val connectivityManager = getSystemService(Context.CONNECTIVITY_SERVICE) as ConnectivityManager These are System Services and the reason they work through getSystemService() rather than as direct API calls comes down to one word: security. System Services getSystemService() security Why Not a Direct API? Why Not a Direct API? Think about what a sensor manager does, it reads hardware values directly from the device's physical sensors. Or consider an SMS manager that can send text messages, or a location manager that can track a user's movements in real time. If these were just plain APIs accessible directly in app code with no oversight, abuse would be trivial. An app could continuously poll all device sensors, draining the battery. Another could query the contacts database and spam every number with SMS messages. There would be no way for the operating system to intervene, rate-limit, or deny access. System services exist precisely to prevent this. They act as gatekeepers between your app and sensitive device functionality. gatekeepers How They Actually Work How They Actually Work Here's the key insight that most Android developers don't realize: System services run in a completely separate process called the System Server. System services run in a completely separate process called the System Server. Your app does not call the sensor manager directly. What actually happens is: Your app's process sends a command across a process boundary to the System Server process
The System Server receives the request, validates it, and decides whether to fulfill it
The response (sensor data, location coordinates, etc.) travels back across the process boundary to your app Your app's process sends a command across a process boundary to the System Server process process boundary The System Server receives the request, validates it, and decides whether to fulfill it The response (sensor data, location coordinates, etc.) travels back across the process boundary to your app This is IPC, the same inter-process communication mechanism we've been studying throughout this series. The difference is that here it happens transparently, managed entirely by the Android framework, without you having to write any IPC code yourself. IPC Because the system service lives in the System Server process and not inside your app, the OS retains full control over every interaction. Consider a few practical consequences of this: Battery management — If your app requests sensor readings too aggressively, the OS can throttle or deny those requests. Since the request goes through the System Server, the OS knows exactly who is asking for what and how often. Battery management Permission enforcement — Dangerous permissions like ACCESS_FINE_LOCATION are checked server-side before the System Server responds. Your app can't bypass this by calling an alternative API, there is no alternative API. Permission enforcement ACCESS_FINE_LOCATION Resource sharing — Multiple apps can receive sensor data from the same hardware sensor simultaneously, because the System Server manages the hardware and fans the data out to all registered clients. No single app monopolizes the hardware directly. Resource sharing This is a textbook client-server architecture, your app is the client, the System Server is the server and the communication channel between them is Android's Binder IPC infrastructure. Why This Matters It's easy to use getSystemService() without thinking about what's behind it. But understanding that you're making an IPC call every time you do, crossing a process boundary, going through the System Server, and coming back. This has real implications: getSystemService() Performance — IPC calls are not free. Crossing a process boundary has overhead compared to a local function call. Batching requests (for example, requesting location updates at a reasonable interval rather than continuously) is not just a battery concern, it's also a latency concern. Performance Failures — System services can be unavailable, throttled, or denied. Code that treats getSystemService() as infallible will be fragile. Null checks, permission handling, and graceful degradation matter here. Failures getSystemService() Security — The permission model you declare in your manifest is not just a formality. It's what the System Server checks before it responds to your IPC request. Without the right permission, the server-side gatekeeper simply refuses. Security Tying It Together Handlers and System Services are both expressions of the same underlying principle that runs throughout this entire series: Android is built on processes communicating with each other. Android is built on processes communicating with each other. A Handler is the mechanism for posting work from one thread to another thread's Looper queue within a process. A System Service is the mechanism for your app's process to request privileged functionality from the System Server process across process boundaries. Both of them, at their core, are about getting the right code to run in the right place at the right time. Once you see it that way, the entire Android threading and IPC model starts to feel far more coherent.

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

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

Android OS Architecture, Part 8: Handlers and System Services Explained

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