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.
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
A Handler is exactly what the name suggests, something that handles the scheduling of a piece of work onto a specific thread.
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.
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
TextViewwith the response data - But UI updates on Android can only happen on the main thread
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.
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.
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.
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:
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.
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.
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.
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
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.
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.
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.
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.
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:
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.
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.
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.
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.
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.