CVE-2026-28602 AI-generated analysis

platform/frameworks/base, services/core ClipboardService (clipboard access notifications)

AI-generated: written from the bulletin and the fixing diffs by claude-fable-5-1, then checked against the code by claude-opus-5-5 (8 corrections). Verify against the commit before relying on it.

ClipboardService now reads and writes the CLIPBOARD_SHOW_ACCESS_NOTIFICATIONS secure setting for the explicit userId (getIntForUser/putIntForUser) instead of getInt/putInt without a user argument, so the clipboard-access notification decision uses the setting of the given user.

Root cause

In services/core/java/com/android/server/clipboard/ClipboardService.java, the path that decides whether to show the clipboard access notification called Settings.Secure.getInt(getContext().getContentResolver(), CLIPBOARD_SHOW_ACCESS_NOTIFICATIONS, mShowAccessNotifications ? 1 : 0) without passing the userId available in that function, and returned early when the value was 0. So the notification gate was not evaluated against the setting of the user identified by userId. The setter setClipboardAccessNotificationsEnabledForUser used Settings.Secure.putInt on a resolver from createContextAsUser(UserHandle.of(userId), 0) without passing userId explicitly. The getter areClipboardAccessNotificationsEnabledForUser already used getIntForUser(..., userId).

How the fix works

• ClipboardService.java, access-notification check (enclosing function not shown in the hunk header; the hunk follows 'if (clipboard.primaryClip == null) return;'): Settings.Secure.getInt(...) is replaced by Settings.Secure.getIntForUser(getContext().getContentResolver(), CLIPBOARD_SHOW_ACCESS_NOTIFICATIONS, (mShowAccessNotifications ? 1 : 0), userId). The early return on value == 0 is unchanged.
• ClipboardService.java: setClipboardAccessNotificationsEnabledForUser(boolean enable, int userId): Settings.Secure.putInt(resolver, CLIPBOARD_SHOW_ACCESS_NOTIFICATIONS, enable ? 1 : 0) is replaced by Settings.Secure.putIntForUser(resolver, CLIPBOARD_SHOW_ACCESS_NOTIFICATIONS, (enable ? 1 : 0), userId). The resolver is still obtained from createContextAsUser(UserHandle.of(userId), 0).
• No other logic changes in the shown code. The MANAGE_CLIPBOARD_ACCESS_NOTIFICATION permission checks and the default (getDefaultClipboardAccessNotificationsSetting / mShowAccessNotifications) are untouched.

Completeness

• Fixes the two accesses touched by the diff. The getter areClipboardAccessNotificationsEnabledForUser already used getIntForUser(..., userId) and is unchanged.
• The fallback default (mShowAccessNotifications) is unchanged and is not per user.
• Only the setting lookup is corrected; the following same-owner suppression logic and the notification itself are unchanged. No regression test is included (Test: Manual).

Behavior changes

• The clipboard access notification for a given user is now gated by that user's own CLIPBOARD_SHOW_ACCESS_NOTIFICATIONS value, so on multi-user devices notifications may now appear or be suppressed differently than before.
• setClipboardAccessNotificationsEnabledForUser writes the setting explicitly for the given userId.
• No new exceptions, error codes or API changes in the diff.

Per major

• Android 14: same fix: DO NOT MERGE commit 6f90eac7f9e5 in android-security-14.0.0_r29; two-hunk diff (setter at ~line 516, notification check at ~line 1364 with 'return;').
• Android 15: same fix: DO NOT MERGE commit 993d9100be4c in android-security-15.0.0_r17; same diff at ~560 and ~1441.
• Android 16: same fix: DO NOT MERGE commit 80b1b1fe63b5 in android-security-16.0.0_r8; same diff at ~553 and ~1438.
• Android 17: adapted fix: 4b3bf7fb29ec in android-security-17.0.0_r1 (not DO NOT MERGE); setter hunk identical, notification hunk follows shouldSuppressAccessNotificationForUidLocked(uid) and uses 'return false;' instead of 'return;'. The getIntForUser(..., userId) change is the same.

Unknowns

• The name of the function containing the notification-check hunk is not shown.
• Which user getContext().getContentResolver() resolves to in the system server is not shown in the material.
• Whether putInt on the user-specific resolver already targeted userId (i.e. whether the setter hunk changes behavior) is not shown.
• Whether other CLIPBOARD_SHOW_ACCESS_NOTIFICATIONS accesses exist elsewhere in ClipboardService.java is not shown.
• No test accompanies the fix (Test: Manual).

Back to September 2026 · Findings