CVE-2026-28642 AI-generated analysis
platform/frameworks/base, WindowManager activity start (services/core/java/com/android/server/wm/ActivityStarter.java)
In ActivityStarter, when the Background Activity Launch (BAL) check returns a blocking verdict, the fix clears the mLaunchTaskBehind flag on the newly built ActivityRecord so a blocked background start does not perform the launch-behind animation that would make the activity visible.
Root cause
In ActivityStarter, around the ActivityRecord.Builder(...).build() call (built with setActivityOptions(checkedOptions)), the BAL result (balCode on Android 14, balVerdict on 15/16) was already available but was not consulted for r.mLaunchTaskBehind: even when the launch was BAL-blocked, the flag remained set, so the launch-behind animation/visibility could still be performed for an activity whose background launch should have been blocked. The commit message states there is no need to perform the launch-behind animation if BAL blocks, and the code comment says the reset avoids making the activity visible when the launch should be blocked.
How the fix works
- services/core/java/com/android/server/wm/ActivityStarter.java (class ActivityStarter, immediately after `new ActivityRecord.Builder(mService)...build()` and before `mLastStartActivityRecord = r`): adds `if (r.mLaunchTaskBehind && balCode == BAL_BLOCK) { Slog.w(TAG, "Disallowed launching behind for a background launch"); r.mLaunchTaskBehind = false; }` on Android 14.
- On Android 15 and 16 the same insertion uses `r.mLaunchTaskBehind && balVerdict.blocks()`; otherwise identical (log + reset of r.mLaunchTaskBehind to false).
- Effect: the launch-behind flag on the record is cleared at creation time for BAL-blocked starts; per the commit message and comment this prevents the launch-behind animation/visibility. The consumers of the flag are not shown in the material. The existing check a few lines later (`if (balCode != BAL_BLOCK && !isHomeProcess) mService.resumeAppSwitches()`) is unchanged.
Completeness
- Covers only the single point where the ActivityRecord is constructed in ActivityStarter; the flag is cleared exactly when the BAL verdict is blocking.
- Does not change the BAL decision itself or how a BAL-blocked start is otherwise handled; that downstream handling is not shown in the material.
- Any other place where mLaunchTaskBehind could be set on a record after this point (not shown in the material) would not be covered by this check.
- Starts that are not BAL-blocked keep the launch-behind flag unchanged.
Behavior changes
- For activity starts whose BAL verdict is blocking and whose record has mLaunchTaskBehind set, the flag is now forced to false; the launch-behind animation/visibility is suppressed.
- A new warning log line is emitted: "Disallowed launching behind for a background launch" (ActivityStarter TAG).
- No new error codes or API changes are visible in the diff; non-blocked starts are unaffected.
Per major
- Android 14: same fix: frameworks/base d94f8b27bc84 in android-security-14.0.0_r29, condition `r.mLaunchTaskBehind && balCode == BAL_BLOCK`; 3/3 patched lines present.
- Android 15: adapted fix: frameworks/base d98cb1490fc3 in android-security-15.0.0_r17, same insertion but condition uses `balVerdict.blocks()`; 3/3 patched lines present.
- Android 16: adapted fix: frameworks/base 2b8a07bf7437 in android-security-16.0.0_r8, same insertion with `balVerdict.blocks()`; 3/3 patched lines present.
- Android 17: not affected (not listed by the bulletin); the patched region (3/3 lines) is already present at android-security-17.0.0_r1.
Unknowns
- Name of the enclosing ActivityStarter method; where balCode/balVerdict is computed and what happens to a BAL-blocked start after this point.
- How mLaunchTaskBehind is set on the record (e.g. from which ActivityOptions setting) and which caller/API path triggers the issue; the bulletin only gives EoP / High.
- Whether other code paths can set mLaunchTaskBehind on an ActivityRecord after this check.
- Contents of the internal commits referenced by the Cherrypick-From trailers; the test was only 'locally verified'.