CVE-2024-0021 AI-generated analysis
platform/packages/apps/Settings, notification access confirmation (NotificationAccessConfirmationActivity)
Adds an early exit to Settings' NotificationAccessConfirmationActivity.onCreate so that, when the activity is running in a managed (work) profile, it shows a toast and finishes instead of presenting the dialog that can enable a notification listener service.
Root cause
NotificationAccessConfirmationActivity is the Settings confirmation activity for granting notification listener access to a component passed via EXTRA_COMPONENT_NAME/EXTRA_USER_ID. Before the fix it did not check whether it was running inside a managed (work) profile. The fix's log message says apps in the work profile do not support notification listeners, and the commit title says a work profile app must not be able to enable notification listener services. The confirmation flow could still be reached from a work profile.
How the fix works
- src/com/android/settings/notification/NotificationAccessConfirmationActivity.java:onCreate: after SYSTEM_FLAG_HIDE_NON_SYSTEM_OVERLAY_WINDOWS is applied, the fix gets UserManager and DevicePolicyManager via getSystemService. If mUm.isManagedProfile() is true, it logs a warning and shows a Toast built from DevicePolicyManager.getResources().getString(WORK_APPS_CANNOT_ACCESS_NOTIFICATION_SETTINGS), with R.string.notification_settings_work_profile as the fallback. It then calls finish() and returns before mNm and mComponentName (from EXTRA_COMPONENT_NAME) are initialized, so the rest of onCreate never runs.
- The fix adds new fields mDpm and mUm, plus imports for DevicePolicyManager, UserManager, Toast and the WORK_APPS_CANNOT_ACCESS_NOTIFICATION_SETTINGS string constant. No other logic in the activity is changed.
Completeness
- The guard covers only the entry point of NotificationAccessConfirmationActivity. It decides based on the user the activity instance runs in (mUm.isManagedProfile()), not on the EXTRA_USER_ID extra in the intent, so it relies on the activity being launched in the requesting profile.
- This commit does not touch other Settings surfaces or framework APIs that can enable notification listeners. The material does not show whether they reject work-profile components on their own.
- The check runs before mNm and mComponentName are initialized, so no partial state is set up before finish().
Behavior changes
- When launched in a managed profile, the activity no longer shows the confirmation dialog. It shows a short toast and finishes immediately. The toast text is the device-policy overridable string WORK_APPS_CANNOT_ACCESS_NOTIFICATION_SETTINGS, defaulting to R.string.notification_settings_work_profile.
- In that case a new Slog warning is emitted: 'Apps in the work profile do not support notification listeners'.
Per major
- Android 14: Same fix: commit 0fb3408e8792 in android-security-14.0.0_r4 (cherry-pick of 81893c2b6f07, Change-Id I7fed6d1baa1a40e9126493d37e33d63236bb4b3c). 8/8 patched lines are present at android-security-14.0.0_r29.
- Android 15: Not affected per the bulletin. The patched region is fully present (8/8) at android-security-15.0.0_r17.
- Android 16: Not affected per the bulletin. The patched region is fully present (8/8) at android-security-16.0.0_r8.
- Android 17: Not affected per the bulletin. The patched region is fully present (8/8) at android-security-17.0.0_r1.
Unknowns
- The material does not show the rest of onCreate, including how EXTRA_USER_ID is validated and how the listener is actually enabled. The exact pre-fix flow that granted access is inferred from the activity's purpose.
- The material does not show whether R.string.notification_settings_work_profile exists in Settings on every target branch.
- The bulletin lists Android 13 as affected, but only the Android 14 commit is provided, so the Android 13 fix is not shown.