How to Inspect Window Hierarchy, Z-Order, and Overlays on Android Using ADB dumpsys window

In modern Android user interfaces, what appears on screen as a single unified visual image is actually an intricate stack of overlapping windows managed by the WindowManagerService (WMS). Beyond the primary application activity, the display hierarchy includes the status bar, navigation bar, system dialogs, keyboard input methods (IME), Picture-in-Picture (PiP) windows, and floating accessibility or chat-head overlays. When touch taps fail to register, animations stutter, or invisible floating overlays intercept user interaction (such as in tapjacking attacks or accessibility bugs), developers require forensic visibility into the window stack. The Android Debug Bridge (ADB) dumpsys window command provides direct inspection of window hierarchies, Z-order layer tokens, and visibility flags.

Understanding the Android Window Manager Hierarchy

The Android Window Manager mediates between application ViewRootImpl instances and the low-level SurfaceFlinger graphics compositor. Each on-screen window is backed by a WindowState object and assigned an integer layer determining its Z-order (depth):

• Application Windows (Layer 1–99): Standard app activities and dialogs.
• Sub-Windows (Layer 1000–1999): Context menus, tooltips, and popups tied to a parent window.
• System Windows (Layer 2000+): High-priority system components, including the status bar, navigation bar, lock screen (Keyguard), system alerts, and overlay permissions (TYPE_APPLICATION_OVERLAY).

The dumpsys window command dumps the active window tree, enabling developers to inspect layout frames, focus states, and display orientation parameters.

Extracting the Window Manager Diagnostic Dump

Connect your Android device to your development computer with USB Debugging enabled and verify authorization:

adb devices

To inspect the entire window manager state, run the general window dump:

adb shell dumpsys window

Because this command outputs the full state machine—including display policies, input method bindings, and animator states—filtering by specific sections yields targeted diagnostic results.

Inspecting the Window Stacking Z-Order

To determine the exact Z-order layering of every visible and hidden window currently mapped to the display, search the dump for the window containers list:

adb shell dumpsys window windows | grep -E "Window #" -A 2

The output prints windows in descending Z-order (from topmost to bottommost):

  Window #7 Window{3a81bc2 u0 NavigationBar}:
    mHasSurface=true isReadyForDisplay()=true
  Window #6 Window{8f12cb4 u0 StatusBar}:
    mHasSurface=true isReadyForDisplay()=true
  Window #5 Window{5b92ea1 u0 com.example.overlay/com.example.overlay.FloatingService}:
    mHasSurface=true isReadyForDisplay()=true
  Window #4 Window{2d48f93 u0 com.example.app/com.example.app.MainActivity}:
    mHasSurface=true isReadyForDisplay()=true
  Window #3 Window{1a457e8 u0 Wallpaper}:
    mHasSurface=true isReadyForDisplay()=true

In this hierarchy:

• Windows at the top of the list (e.g., NavigationBar and StatusBar) render above lower windows.
• com.example.overlay sits at Layer 5, directly above MainActivity at Layer 4. If taps on MainActivity are unresponsive, this confirms that the floating overlay window is intercepting touch coordinates.

Auditing Focused Windows and App Tokens

When hardware key presses (like volume or back gestures) fail to respond within an application, query which window currently holds input focus:

adb shell dumpsys window | grep -E "(mCurrentFocus|mFocusedApp)"

The terminal outputs the currently focused window token:

mCurrentFocus=Window{2d48f93 u0 com.example.app/com.example.app.MainActivity}
mFocusedApp=AppWindowToken{... token=ActivityRecord{... com.example.app/.MainActivity}}

If mCurrentFocus displays null or points to an unexpected background service, the main application has lost focus, preventing touch event dispatch.

Detecting Invisible and Transparent Floating Overlays

Malicious applications or poorly architected background services sometimes leave 1×1-pixel transparent windows or FLAG_NOT_TOUCH_MODAL overlay surfaces running. These can intercept touch gestures or capture private data.

To audit all windows with overlay window types (TYPE_APPLICATION_OVERLAY or legacy TYPE_SYSTEM_ALERT):

adb shell dumpsys window | grep -B 2 -A 6 "type=TYPE_APPLICATION_OVERLAY"

The output exposes the package name and dimensions of the overlay window, allowing you to identify the culprit package and revoke its “Display over other apps” permission in Settings.

Inspecting Physical Layout Frames and Cutout Insets

When UI layouts overlap camera punch-holes, curved corners, or navigation gesture bars, inspect the exact layout frames calculated by the window manager:

adb shell dumpsys window | grep -A 8 "Frames: containing="

This displays the raw rectangle bounds (e.g., containing=[0,0][1080,2400], parent=[0,120][1080,2280]), showing the precise system insets passed to your app’s WindowInsets handlers.

Mastering dumpsys window equips developers with complete structural clarity over Android’s multi-layered UI stack, simplifying gesture debugging and securing applications against overlay interference.