CVE-2026-28599 AI-generated analysis
platform/frameworks/base, ActivityManagerService (intent redirect hardening / IntentCreatorToken)
In ActivityManagerService.addCreatorToken, the targetPackage used for the isCreatorSameAsTarget shortcut no longer falls back to intent.getPackage() when the outer intent has no explicit component. In that case creator tokens are now attached to nested intents instead of being skipped because of a package constraint the caller controls and that a selector could override.
Root cause
addCreatorToken decides whether to skip attaching IntentCreatorTokens to nested intents. It computes targetPackage and checks creatorPackage.equals(targetPackage) (isCreatorSameAsTarget). Before the fix, when the outer intent had no explicit component, targetPackage came from intent.getPackage(). That value does not determine routing when the intent carries a selector: per the commit message, ComputerEngine routes on the selector's explicit component. A caller could therefore set the outer intent's package to its own package, which made isCreatorSameAsTarget true so the forEachNestedCreatorToken callback returned early without calling createIntentCreatorToken. At the same time a selector could target another app's component, so the nested intents were delivered without creator tokens.
How the fix works
- services/core/java/com/android/server/am/ActivityManagerService.java:addCreatorToken: the ternary that computes targetPackage now returns null instead of intent.getPackage() when intent.getComponent() is null. With targetPackage null, creatorPackage.equals(targetPackage) is false, so isCreatorSameAsTarget is false. The forEachNestedCreatorToken lambda then calls createIntentCreatorToken(extraIntent, creatorUid, creatorPackage) and calls extraIntent.setCreatorToken(...) whenever a non-null token is returned. createIntentCreatorToken returns null if the nested intent already has a valid token.
- The explicit-component branch is unchanged: when intent.getComponent() is non-null, targetPackage is still intent.getComponent().getPackageName() and the same-package shortcut still applies.
- The shipped diff (both Android 16 and 17) is a one-line change that removes the getPackage() fallback entirely. It does not implement the selector-aware priority logic described in the commit message (outer component, then selector component or package, then outer package). The shipped behavior is more conservative than that description.
Completeness
- Covers the described bypass: when the outer intent has no explicit component, the same-package shortcut can no longer trigger, whatever intent.getPackage() or the selector contain.
- The shortcut still exists for outer intents with an explicit component and is based only on that component's package. The material does not show whether a selector can influence routing in that case. In the platform resolver the outer explicit component takes precedence over the selector (general platform knowledge), which would make this branch match actual routing.
- addCreatorToken is still gated by preventIntentRedirect() and the intent != null check. The fix does not change that gating. The nested-key flags (wtf log, toast, optional SecurityException, server-side key collection) are also unchanged.
- addCreatorToken still does not inspect the selector. The fix avoids the selector question instead of modelling it.
Behavior changes
- When the creator token path is active, nested intents inside an outer intent with no explicit component now get IntentCreatorTokens even when intent.getPackage() equals the creator's package. Previously the shortcut skipped them.
- FrameworkStatsLog INTENT_CREATOR_TOKEN_ADDED is logged with false (token created) in more cases, and createIntentCreatorToken is called more often.
- This diff adds no new error or exception paths.
Per major
- Android 14: Not affected per the bulletin. At android-security-14.0.0_r29 only 2/5 lines of the patched region are present. No fix was applied.
- Android 15: Not affected per the bulletin. At android-security-15.0.0_r17 only 2/5 lines of the patched region are present. No fix was applied.
- Android 16: Same fix. Commit 5108d2606324 in android-security-16.0.0_r8 is a one-line change in ActivityManagerService.addCreatorToken (around line 19462). 5/5 patched lines are present.
- Android 17: Same fix. Commit ee7ea482d39e in android-security-17.0.0_r1 makes the identical one-line change at a different offset (hunk at line 21098). 5/5 patched lines are present.
Unknowns
- The material does not show the callers of addCreatorToken or the exact entry points.
- Whether the two internal Cherrypick-From commits contained more changes (for example tests or the described selector-aware logic) than the one-line diff shipped to AOSP.
- The state of the preventIntentRedirect() flag on shipping builds is not shown.
- Whether addCreatorToken and the creator-token hardening exist on Android 14/15. Only 2/5 lines of the patched region are present there, and the bulletin does not list those versions.