CVE-2025-32350 AI-generated analysis
platform/frameworks/base, SystemUI device controls (packages/SystemUI, controls/settings)
Removes android:exported="true" from SystemUI's ControlsActivity manifest entry and adds SYSTEM_FLAG_HIDE_NON_SYSTEM_OVERLAY_WINDOWS to the window of the dialog created by ControlsSettingsDialogManager, so non-system windows are not drawn on top of it.
Root cause
In packages/SystemUI/AndroidManifest.xml, the commit subject identifies the activity as ControlsActivity. The hunk shows launchMode singleInstance and visibleToInstantApps, and the element sits right before .wallet.ui.WalletActivity. It was declared android:exported="true", so it was exposed to other apps. In addition, the AlertDialog built in ControlsSettingsDialogManager.kt (the dialog that prompts the user to enable Settings.Secure.LOCKSCREEN_SHOW_CONTROLS / LOCKSCREEN_ALLOW_TRIVIAL_CONTROLS) was shown without SYSTEM_FLAG_HIDE_NON_SYSTEM_OVERLAY_WINDOWS, so non-system windows could be drawn over this prompt.
How the fix works
- packages/SystemUI/AndroidManifest.xml: drops the android:exported="true" attribute from the ControlsActivity <activity> element (per the commit subject). The hunk does not show whether the element has an intent-filter, so the resulting exported state is inferred from the commit subject ('Unexport ControlsActivity').
- packages/SystemUI/src/com/android/systemui/controls/settings/ControlsSettingsDialogManager.kt (dialog construction in the implementation class, the path exercised by maybeShowDialog): after the AlertDialog `d` is built and before SystemUIDialog.registerDismissListener/setDialogSize/setShowForAllUsers, the fix adds `d.window?.addSystemFlags(SYSTEM_FLAG_HIDE_NON_SYSTEM_OVERLAY_WINDOWS)` and imports android.view.WindowManager.LayoutParams.SYSTEM_FLAG_HIDE_NON_SYSTEM_OVERLAY_WINDOWS.
- packages/SystemUI/tests/src/com/android/systemui/controls/settings/ControlsSettingsDialogManagerImplTest.kt: a new test, dialogHidesNonSystemOverlayWindows, sets attempts=0 and both settings to false, calls underTest.maybeShowDialog(context, completedRunnable), and asserts that the dialog window's attributes.privateFlags contain SYSTEM_FLAG_HIDE_NON_SYSTEM_OVERLAY_WINDOWS.
Completeness
- Covers the two things in the diff: the one manifest activity is unexported, and the single dialog created in ControlsSettingsDialogManager.kt gets the overlay-hiding flag.
- No permission or caller check is added to the activity; the fix relies on removing the exported attribute. The material does not show whether the activity has an intent-filter elsewhere in the element (the hunk only shows trailing attributes), which would matter for the exported default.
- Only this dialog is hardened. The material does not show other controls-related dialogs or activities, so whether they already carry the flag is unknown from the diff.
Behavior changes
- ControlsActivity is no longer declared exported, so third-party apps are expected to lose the ability to launch it directly. The exact failure mode for external callers is not shown in the material.
- Per the commit message, non-system windows are not drawn on top of the controls settings dialog while it is displayed.
- No change to the dialog's content, button handling, or attempt counting.
Per major
- Android 14: same fix: b08dcc947008 in android-security-14.0.0_r22 (linked by subject to the Android 16 reference d6b86833ee06). The manifest and Kotlin changes are identical. The only differences are the R import (com.android.systemui.R) and the test file also adding an androidx.test.ext.junit.runners.AndroidJUnit4 import. 8/8 lines present at android-security-14.0.0_r29.
- Android 15: same fix: 47424521c49b in android-security-15.0.0_r10 (matched by Change-Id I6280b501b799596099935dc61ecef0b431dd8333); uses com.android.systemui.res.R. 8/8 lines present at android-security-15.0.0_r17.
- Android 16: same fix: d6b86833ee06 in android-security-16.0.0_r1 (matched by bug id 404256832); same content as 15. 8/8 lines present at android-security-16.0.0_r8.
- Android 17: not affected (not listed by the bulletin); the patched region is present (8/8 lines) at android-security-17.0.0_r1.
Unknowns
- The manifest hunk does not show the android:name of the modified activity, whether it has an intent-filter, or whether it has a permission attribute. The identification as ControlsActivity comes from the commit subject.
- The material does not show what ControlsActivity does when launched externally, so the concrete EoP impact of the exported state is not shown.
- The material does not show the exact failure an external caller now gets when trying to launch the activity.
- The Android 14 commit is linked to the reference only by subject (probable match), not by Change-Id or bug id, although its content is identical apart from the imports.