The Missing Sense of Space
ActivityManagerService tracks which applications are currently running. It knows the lifecycle state of your application perfectly. But ActivityManagerService has zero understanding of physical screen space. It cannot tell if your application is in split-screen mode or floating as a tiny picture-in-picture window. When a user opens a dialog box, something else must calculate exactly where those pixels belong on the physical glass.
The WindowManagerService solves this geometry problem. It acts as the spatial architect of the Android system. The service does not actually draw any pixels to the screen, as that job belongs exclusively to SurfaceFlinger. Instead, WindowManagerService calculates the absolute boundaries, scaling, and Z-ordering for every single visual element.
By separating the math from the rendering, Android keeps the graphics pipeline fast. WindowManagerService performs the heavy calculations for window placement and animations. It then hands those precise coordinates down to SurfaceFlinger for the final composition.
This leads to a massive organizational challenge. When users connect external displays and open multiple floating windows, tracking every coordinate manually becomes impossible.
Structuring the Screen Real Estate
Managing multiple displays, popup dialogs, and system bars requires strict structural organization. A flat list of windows would become chaotic immediately. WindowManagerService solves this by organizing every visual element into a massive, heavily regulated tree structure.
You are about to see the Window Hierarchy diagram. This visualizes how Android maps a physical screen down to an individual window. Look for how a single Activity node can own multiple WindowState nodes.
The root node is DisplayContent, representing a physical screen. If you cast your device to a TV, Android creates a second DisplayContent root entirely. Below that sits the TaskArea, which defines where applications can safely draw while avoiding permanent system bars. This flows down to the Task and ActivityRecord, mirroring the application state managed by ActivityManagerService. Finally, the WindowState represents the literal window containing your UI views.
When you need to verify if a window is placed correctly, you can inspect this entire nested tree directly from the terminal. Running the following command outputs a massive text representation of the current hierarchy, showing exact coordinates and tokens for every active window.
adb shell dumpsys window windows
Common Mistake: Running this command directly will flood your terminal with thousands of lines. You usually want to pipe the output into
grepto find your specific application package.
Understanding this tree helps you debug complex visual layout issues. But raw structural organization does not stop a malicious application from simply requesting a window placement at the top of the tree.
Defending Against Overlay Attacks
If applications had free control over window placement, the system would be fundamentally insecure. A malicious application could draw a fake password prompt directly on top of your banking application. Android prevents this overlay attack using strict Window Tokens.
A Window Token is a secure Binder object that acts as a ticket for screen real estate. When ActivityManagerService launches an activity, it generates this token and passes it to WindowManagerService. Any application wanting to add a window to the screen must present this exact token back to WindowManagerService.
Missing tokens or attempts to draw outside permitted bounds cause WindowManagerService to instantly reject the request. Only highly privileged system processes receive powerful overlay tokens, like the TYPE_SYSTEM_OVERLAY token used to draw the status bar. This strict token validation guarantees that only authorized applications can draw over others.
But placing a window securely is only half the battle. Once the window is drawn, the user will try to touch it.
Routing Touches to the Right Application
When a user taps the glass, the kernel touch driver sends bare X and Y coordinates to the InputManagerService. The kernel does not know about Android applications. The InputManagerService also has no idea which application is currently visible at those specific coordinates.
WindowManagerService solves this problem by continuously sharing its calculated bounding boxes and Z-order map with the InputManagerService.
You are about to see a sequence diagram showing this interaction. This clarifies why WindowManagerService and InputManagerService work so closely together. Notice how the hit test happens entirely inside InputManagerService, not WindowManagerService.
InputManagerService performs a mathematical hit test against the WindowManagerService bounding boxes to figure out which window the coordinates intersected. Once InputManagerService identifies the topmost valid window, it routes the touch event directly to that specific application over a dedicated socket.
WindowManagerService is therefore responsible for much more than what you see. By defining the physical boundaries of every window, it directly controls which application receives your touch events.
We now have the final piece of the visual puzzle. WindowManagerService calculates exactly where the windows belong, but it refuses to draw a single pixel. Those precise coordinates must be handed off to the system component that actually commands the graphics hardware.