CVE-2025-0100 AI-generated analysis
platform/frameworks/base, SystemUI MediaProjection permission dialog (packages/SystemUI/src/com/android/systemui/media/MediaProjectionPermissionActivity.java)
MediaProjectionPermissionActivity.onCreate now takes the requesting package from getLaunchedFromPackage() instead of getCallingPackage(), and still uses getCallingPackage() == null to pick out the system_server launch path.
Root cause
In MediaProjectionPermissionActivity.onCreate, mPackageName was assigned from getCallingPackage(). That value is then passed to packageManager.getApplicationInfo(mPackageName, 0) to derive mUid. According to the commit message, the change makes sure the activity does proper attribution and validation of permissions before showing. The fix changes the source of the package identity to getLaunchedFromPackage().
How the fix works
- packages/SystemUI/src/com/android/systemui/media/MediaProjectionPermissionActivity.java:onCreate - `mPackageName = getCallingPackage();` is replaced with `mPackageName = getLaunchedFromPackage();`, so the package name passed to getApplicationInfo (and so mUid) now comes from getLaunchedFromPackage().
- Same function - the branch condition `if (mPackageName == null)` becomes `if (getCallingPackage() == null)`. This keeps the existing split between the app-launched path and the system_server path. When there is no calling package, the package still comes from EXTRA_PACKAGE_REUSING_GRANTED_CONSENT if that extra is present. Otherwise the activity sets RESULT_CANCELED and calls finish(RECORD_CANCEL, null).
- Single commit with two logical hunks (plus removal of a blank line). It adds no new helpers or dependencies.
Completeness
- Covers the app-launched path: the package identity used for the lookup now comes from getLaunchedFromPackage().
- The system_server path (getCallingPackage() == null with EXTRA_PACKAGE_REUSING_GRANTED_CONSENT present) still takes mPackageName from an intent extra. The code comment says system_server provides it, and the fix adds no check on that extra.
- mUid is still found by looking up the package name with getApplicationInfo(mPackageName, 0), not taken directly from the launching uid. The fix only changes which package name goes into that lookup.
- No other files or callers change. The index search returned no relevant callers, so it supports no further conclusions.
Behavior changes
- The request is now attributed to the package returned by getLaunchedFromPackage() rather than getCallingPackage().
- If that package cannot be resolved by getApplicationInfo, the activity logs 'Unable to look up package name' and cancels (RESULT_CANCELED / RECORD_CANCEL), the same handling as before for a name that cannot be resolved.
- The system_server path (package taken from the intent extra when there is no calling package) is unchanged.
Per major
- Android 14: Same fix: commit d37b2f8bc6b6 in android-security-14.0.0_r17 (RESTRICT AUTOMERGE cherry-pick, Change-Id I48adb14fbc8d5f2f2e21ef8a30a713d33f03ab02) at packages/SystemUI/src/com/android/systemui/media/MediaProjectionPermissionActivity.java. At android-security-14.0.0_r29, 7 of 8 lines of the patched region are present.
- Android 15: Same fix in a different file location: commit 0e462ffab772 in android-security-15.0.0_r5 changes packages/SystemUI/src/com/android/systemui/mediaprojection/permission/MediaProjectionPermissionActivity.java with the same hunk content. At android-security-15.0.0_r17, 7 of 8 lines of the patched region are present.
- Android 16: Not affected (the bulletin does not list it). The patched file is absent at android-security-16.0.0_r8.
- Android 17: Not affected (the bulletin does not list it). The patched file is absent at android-security-17.0.0_r1.
Unknowns
- The concrete scenario in which getCallingPackage() and getLaunchedFromPackage() diverge for this activity is not shown in the material.
- How mPackageName is used after the getApplicationInfo lookup (dialog text, the projection grant) is not shown in the code context.
- Whether anything other than system_server can supply EXTRA_PACKAGE_REUSING_GRANTED_CONSENT is not shown.
- Where the equivalent consent-activity code lives on Android 16/17, if anywhere, is not shown.