CVE-2026-0021 AI-generated analysis

platform/packages/apps/Settings, applications/AppInfoBase (app info pages) and AndroidManifest.xml

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

In packages/apps/Settings, AppInfoBase's caller permission check now, on devices with activity embedding (multi-pane) enabled, verifies that the SettingsActivity's initial calling package holds INTERACT_ACROSS_USERS_FULL instead of relying on getLaunchedFromUid, and the Settings$AppUsageAccessSettingsActivity intent-filter gets android:priority="1".

Root cause

AppInfoBase has a method (its name is not shown in the hunk header) that, after confirming the host activity is a SettingsActivity, decides whether the caller is allowed through by using ActivityManager.getService().getLaunchedFromUid(activity.getActivityToken()). Per the commit title ('Check permission of the calling package in multi-pane devices'), this check was not adequate on devices where ActivityEmbeddingUtils.isEmbeddingActivityEnabled(activity) is true. The material does not show exactly why the launched-from UID check fails in that mode. Separately, the Settings$AppUsageAccessSettingsActivity intent-filter for android.settings.USAGE_ACCESS_SETTINGS with data scheme "package" had no priority, while its sibling Settings$UsageAccessSettingsActivity already declares priority 1.

How the fix works

• src/com/android/settings/applications/AppInfoBase.java (caller permission method, after the SettingsActivity instanceof check): adds a branch for ActivityEmbeddingUtils.isEmbeddingActivityEnabled(activity). It obtains ((SettingsActivity) activity).getInitialCallingPackage(); if that is empty, it logs and returns false. It then requires mPm.checkPermission(Manifest.permission.INTERACT_ACROSS_USERS_FULL, callingPackageName) == PERMISSION_GRANTED; otherwise it logs and returns false. On success it returns true. The pre-existing getLaunchedFromUid path is only reached when embedding is not enabled.
• src/com/android/settings/applications/AppInfoBase.java: adds import com.android.settings.activityembedding.ActivityEmbeddingUtils.
• AndroidManifest.xml: the Settings$AppUsageAccessSettingsActivity intent-filter (USAGE_ACCESS_SETTINGS, scheme package) changes from <intent-filter> to <intent-filter android:priority="1">, matching the sibling Settings$UsageAccessSettingsActivity. The commit message does not explain this change. A higher intent-filter priority makes an activity rank ahead of other matching activities during resolution (general platform knowledge).

Completeness

• The new check applies only when ActivityEmbeddingUtils.isEmbeddingActivityEnabled(activity) is true. The non-embedding path still uses getLaunchedFromUid and is unchanged.
• On the embedding path the check is keyed on a package name from SettingsActivity.getInitialCallingPackage() and uses PackageManager.checkPermission(permission, packageName), not a UID. The material does not show how SettingsActivity derives the initial calling package.
• Only the AppInfoBase method is changed. The material does not show which fragments rely on it, or whether other Settings fragments perform a similar getLaunchedFromUid-based check.
• The manifest priority change is applied only to Settings$AppUsageAccessSettingsActivity. The surrounding context shows that the sibling Settings$UsageAccessSettingsActivity already had priority 1.

Behavior changes

• On multi-pane devices, AppInfoBase now denies (returns false, with a Log.w) when the initial calling package cannot be determined, or when that package lacks INTERACT_ACROSS_USERS_FULL.
• On multi-pane devices the getLaunchedFromUid-based check is no longer consulted. The result is decided only by the calling-package permission check.
• The USAGE_ACCESS_SETTINGS/package-scheme filter of Settings$AppUsageAccessSettingsActivity now has priority 1, which can change which activity is chosen when several activities match that intent.

Per major

• Android 14: same fix: commit 19171d5c31ad in android-security-14.0.0_r25 (cherry-pick of bd4d57ade079, Change-Id I91dafa77d07970fdf2628b4d9e89ca1c4b74194c); 8/8 lines of the patched region present at android-security-14.0.0_r29.
• Android 15: same fix: commit 298fd46325a8 in android-security-15.0.0_r13; same diff content (different line offsets); 8/8 lines present at android-security-15.0.0_r17.
• Android 16: same fix: commit 48af8a13dd12 in android-security-16.0.0_r4; same diff content; 8/8 lines present at android-security-16.0.0_r8.
• Android 17: not affected: not listed by the bulletin; 8/8 lines of the patched region already present at android-security-17.0.0_r1.

Unknowns

• The name and full body of the patched AppInfoBase method, and how callers use its result.
• Why the getLaunchedFromUid-based check is insufficient on multi-pane devices.
• How SettingsActivity.getInitialCallingPackage() is populated, and whether it is trustworthy in all launch paths.
• Which fragments (for example, whether UsageAccessDetails extends AppInfoBase) and which exported activities reach the patched check.
• The exact reason for the manifest priority change on Settings$AppUsageAccessSettingsActivity (the commit message does not state it).
• Which user mPm.checkPermission evaluates for the calling package name.

Back to March 2026 · Findings