If the ActivityManagerService (AMS) decides what app is running, the WindowManagerService (WMS) decides exactly where and how it appears on the screen.
WMS is the second most complex service in the Android System Server. It does not actually draw the pixels on the screen (that is the job of SurfaceFlinger), but it dictates the absolute geometry, animations, and Z-ordering (which window is on top of which) of every visual element.
The Window Hierarchy
To manage complex UIs like split-screen, picture-in-picture, and multi-display setups, WMS organizes windows in a massive, nested tree structure known as the Window Hierarchy.
DisplayContent: The absolute root node representing a physical screen. If you cast your screen to a TV, a secondDisplayContentroot is created.TaskDisplayArea: Represents the section of the screen where apps are allowed to draw (excluding the permanent navigation bar and status bar).Task: Represents an app's back stack (coordinated with AMS).ActivityRecord: Represents the individual Activity screen.WindowState: Represents the actual, literal window holding the UI views. A single Activity might have multipleWindowStates(e.g., the main UI window and a separate pop-up dialog window).
# Dump the entire nested WMS window hierarchy to the terminal
adb shell dumpsys window windows
Window Tokens and Security
Why can't a malicious app draw a fake "Enter Password" screen directly on top of your banking app? Because of Window Tokens.
When AMS launches an Activity, it generates a highly secure Binder token and passes it to WMS. When the app wants to draw a window, it must present this exact token to WMS. If the token is invalid, or if the app tries to draw outside of its permitted bounds or layer (Z-index), WMS instantly rejects the request.
Only system-level processes (like the SystemUI drawing the status bar) are granted the powerful TYPE_SYSTEM_OVERLAY tokens that allow them to draw on top of everything else.
Input Dispatch
WMS is also deeply tied to the InputManagerService (IMS).
When a user taps the physical screen, the kernel touch driver sends the X/Y coordinates to the IMS. But how does IMS know which app was actually tapped?
WMS calculates the exact bounding boxes and Z-order of all visible windows and passes this map to IMS. IMS then performs a mathematical "hit test" to figure out which window the X/Y coordinate intersected, and explicitly routes the touch event to that specific app's window over a dedicated socket.