CVE-2026-28663 AI-generated analysis

platform/frameworks/base, LauncherAppsService (services/core/java/com/android/server/pm), PendingIntent / background activity launch (BAL) restrictions

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 (3 corrections). Verify against the commit before relying on it.

LauncherAppsService.buildIntentSenderForUser now passes ActivityOptions with PendingIntentCreatorBackgroundActivityStartMode set to MODE_BACKGROUND_ACTIVITY_START_ALLOW_IF_VISIBLE when it creates the system-owned PendingIntent that getAppMarketActivityIntent returns. The creator's background-activity-start privilege therefore no longer applies when the app sending the IntentSender is not visible.

Root cause

LauncherAppsService.buildIntentSenderForUser (used by buildAppMarketIntentSenderForUser for getAppMarketActivityIntent) called PendingIntent.getActivityAsUser with options == null. Per the commit message, the call runs with cleared calling identity, so the PendingIntent is created on behalf of system_server (UID 1000) and inherits the creator's background-activity-start privileges. The resulting IntentSender was returned to arbitrary apps. An unprivileged app that triggered its send (the commit cites use as a notification deleteIntent) could start an activity from the background, bypassing BAL restrictions.

How the fix works

• services/core/java/com/android/server/pm/LauncherAppsService.java:buildIntentSenderForUser builds a Bundle via ActivityOptions.makeBasic().setPendingIntentCreatorBackgroundActivityStartMode(ActivityOptions.MODE_BACKGROUND_ACTIVITY_START_ALLOW_IF_VISIBLE).toBundle() and passes it as the options argument of PendingIntent.getActivityAsUser instead of null.
• The flags (FLAG_IMMUTABLE | FLAG_UPDATE_CURRENT), request code, intent and user are unchanged. The system still creates the PendingIntent (which preserves cross-profile behaviour, per the commit message), but it now carries a creator-side BAL mode that only permits activity starts when the sending app is visible.
• Single commit. The Android 17 commit b8e217c4e6cd has identical hunk content at different line offsets: new-side hunks start at 1867/1880 on Android 17 versus 1824/1837 on Android 16.

Completeness

• Covers every PendingIntent produced through buildIntentSenderForUser, i.e. the app-market IntentSender from buildAppMarketIntentSenderForUser / getAppMarketActivityIntent. Per index search, there are no other callers of buildIntentSenderForUser.
• The code context shows a second, separate PendingIntent.getActivityAsUser call at lines 1803-1809 (psSettingsIntent, inside a try block whose finally calls Binder.restoreCallingIdentity). It still passes null options and this commit does not change it. The material does not show whether unprivileged callers can reach it or whether other mitigations apply.
• The fix relies on the ALLOW_IF_VISIBLE creator mode rather than removing the privileged creation. It does not add caller checks to getAppMarketActivityIntent.

Behavior changes

• The IntentSender returned by getAppMarketActivityIntent now carries MODE_BACKGROUND_ACTIVITY_START_ALLOW_IF_VISIBLE as the creator BAL mode. If the sending app is not visible, the creator's privilege no longer allows the app-market activity to start from the background. Visible senders are unaffected.
• No API signature, flag, or return-value changes. null is still returned when PendingIntent creation fails.

Per major

• Android 14: Not affected per the bulletin. The resolver reports 6/8 lines of the patched region at android-security-14.0.0_r29, so some form of the surrounding code exists there, but no fix is recorded. The material does not show the status of the fix in 14.
• Android 15: Not affected per the bulletin. The resolver reports 8/8 lines of the patched region at android-security-15.0.0_r17. The material does not show whether this reflects the fixed code or only matching context lines.
• Android 16: Same fix: commit 05c5903d27b8 in android-security-16.0.0_r8 (cherry-pick of internal changes 0c7caef3 / 341e2f0e, Change-Id Ida112cd1).
• Android 17: Same fix: commit b8e217c4e6cd in android-security-17.0.0_r1, identical hunk content with new-side hunks at lines 1867/1880.

Unknowns

• The shown context does not include where clearCallingIdentity is called around buildIntentSenderForUser, or the permission checks on getAppMarketActivityIntent. Only the commit message describes them.
• Whether the Android 14/15 branches contain equivalent vulnerable code or the fix: the bulletin does not list them, and the resolver line counts (6/8, 8/8) are ambiguous.
• Which method the second null-options PendingIntent at lines 1803-1809 belongs to, and who can call it.

Back to September 2026 · Findings