CVE-2024-34741 AI-generated analysis
platform/frameworks/base, WindowManager (services/core/java/com/android/server/wm/WindowState.java)
WindowState.setForceHideNonSystemOverlayWindowIfNeeded now classifies a window by getBaseType() instead of mAttrs.type. Per the commit title 'Hide SAW subwindows', this means subwindows of system-alert-window (SAW) or toast parents are also force-hidden when a top window hides overlays through Window#setHideOverlayWindows.
Root cause
setForceHideNonSystemOverlayWindowIfNeeded decided whether the 'hide non-system overlay windows' policy applies to a window by testing mAttrs.type against isSystemAlertWindowType() and TYPE_TOAST. A subwindow attached to a SAW parent has its own subwindow type, so the early return fired and the subwindow was not hidden. The TYPE_APPLICATION_OVERLAY system-overlay exemption was also evaluated on mAttrs.type. Per the commit message, SAW subwindows could therefore stay shown while the top window had overlays hidden through Window#setHideOverlayWindows.
How the fix works
- services/core/java/com/android/server/wm/WindowState.java:setForceHideNonSystemOverlayWindowIfNeeded: adds `final int baseType = getBaseType();` and uses baseType in the first early-return check (`!isSystemAlertWindowType(baseType) && baseType != TYPE_TOAST`).
- Same function: the system-application-overlay exemption (`baseType == TYPE_APPLICATION_OVERLAY && mAttrs.isSystemApplicationOverlay() && mSession.mCanCreateSystemApplicationOverlay`) is now also evaluated on baseType.
- The rest of the function is unchanged: when the force-hide state changes, it calls hide(true, true) or show(true, true). Per index search, WindowManagerService.updateNonSystemOverlayWindowsVisibilityIfNeeded calls this function for every window through mRoot.forAllWindows, so the subwindows affected by the change are now hidden and shown in the same pass.
Completeness
- The fix covers the classification point used by the hide-overlay-windows mechanism (setForceHideNonSystemOverlayWindowIfNeeded). The mSession.mCanAddInternalSystemWindow bypass is unchanged.
- The sibling function setHiddenWhileSuspended in the same file already uses getBaseType() in the r29 context, so the suspended-app path is consistent with this fix.
- No other callers or policy checks were modified in this commit.
- This is a single-commit fix. The referenced test is CtsWindowManagerDeviceWindow:HideOverlayWindowsTest.
Behavior changes
- Windows whose base type is a system alert window type or TYPE_TOAST, owned by a session without mCanAddInternalSystemWindow, are now hidden (hide(true, true)) while any window with hideNonSystemOverlayWindowsWhenVisible() is shown. They are shown again when that state clears. This now includes such subwindows.
- The system application overlay exemption is now evaluated on the base type, so it also applies to such subwindows.
- No new error codes or API changes. This is a visibility policy change inside WindowManagerService.
Per major
- Android 14: Same fix: commit abfaf702ef83 in android-security-14.0.0_r11 (cherry-pick of c37bc9147086). At android-security-14.0.0_r29 the function uses baseType for both checks.
- Android 15: Not affected per the bulletin. At android-security-15.0.0_r17, 3/5 lines of the patched region are present, the same ratio as 14 r29. This is consistent with the fix being present.
- Android 16: Not affected per the bulletin. At android-security-16.0.0_r8, 3/5 lines of the patched region are present, consistent with the fix being present.
- Android 17: Not affected per the bulletin. At android-security-17.0.0_r1, 3/5 lines of the patched region are present, consistent with the fix being present.
Unknowns
- The commit identifiers and code shape for Android 12, 12L and 13 (listed as affected) are not in the material.
- The actual code at the 15/16/17 tags is not shown. Only the 3/5 line-match measurement is given.
- The implementation of getBaseType() is not shown in the material.