CVE-2024-49733 AI-generated analysis
platform/frameworks/base, packages/SettingsLib (com.android.settingslib.applications.ServiceListing)
ServiceListing.reload() in SettingsLib now always includes every component already approved in the backing Settings.Secure setting (queried explicitly by ComponentName), instead of only listing services that currently match the intent action, declared permission and validator, so previously approved services no longer disappear from the list given to callbacks.
Root cause
ServiceListing.reload() built mServices only from pmWrapper.queryIntentServicesAsUser(new Intent(mIntentAction), ...). It then dropped any ServiceInfo whose info.permission did not equal mPermission or that failed mValidator.test(info). The set of approved components (mEnabledServices, parsed from Settings.Secure mSetting in loadEnabledServices()) was never used when building the list. A component that was approved earlier, possibly under laxer criteria, and that now does not resolve for mIntentAction, does not declare mPermission, or fails the validator was therefore left out of the list delivered to Callback.onServicesReloaded(), even though it stayed approved in the setting.
How the fix works
- packages/SettingsLib/src/com/android/settingslib/applications/ServiceListing.java:reload(): the first loop over the mIntentAction query now applies the permission check and mValidator only to components that are NOT in mEnabledServices. Components that pass are added to mServices as before. Components that are already enabled are skipped in this loop.
- ServiceListing.java:reload(): a new second loop goes through mEnabledServices. For each ComponentName cn it calls pmWrapper.queryIntentServicesAsUser(new Intent().setComponent(cn), flags, user) and adds every returned resolveInfo.serviceInfo to mServices with no permission or validator filtering. As a result, every approved component that still resolves is always listed.
- packages/SettingsLib/tests/robotests/.../ServiceListingTest.java: adds testHasPermissionWithoutMeetingCurrentRegs. The test approves pkg2/service2 in TEST_SETTING, makes it fail the validator and keeps it out of the action query. It then asserts that pkg2/service2 is still delivered, together with the validated pkg service, and that queryIntentServicesAsUser is called twice. Existing tests now also set service names (s1.name/s2.name), presumably because the new code calls getComponentName().
Completeness
- Covers the listing path only: ServiceListing.reload() now shows all approved components that resolve through an explicit component query for the current user with the same flags.
- Approved components that no longer resolve at all (the query returns nothing) are still not listed. The fix does not prune or otherwise change the stored approvals in mSetting.
- The approval logic itself (setEnabled / saveEnabledServices) is unchanged. The fix only makes existing grants visible.
- The second loop deliberately applies neither the mPermission check nor mValidator to approved components. The commit message says this is intended ('Regardless of what the current criteria is').
Behavior changes
- Services whose component is in the Settings.Secure setting now appear in the list passed to Callback.onServicesReloaded() even if they do not match mIntentAction, do not declare mPermission, or fail mValidator.
- reload() makes one extra queryIntentServicesAsUser call per approved ComponentName. The test asserts 2 calls with one approved component.
- The 'Skipping ... does not require the permission' warning is no longer logged for components that are already approved.
Per major
- Android 14: same fix: platform/frameworks/base 8516dfb89f99 in android-security-14.0.0_r16 (cherry-pick of 234c5e843ca4); 8/8 patched lines present at android-security-14.0.0_r29.
- Android 15: same fix: platform/frameworks/base 3b2be226f1b9 in android-security-15.0.0_r4, same diff; 8/8 lines present at android-security-15.0.0_r17.
- Android 16: not affected (not listed by the bulletin); the patched code is present at android-security-16.0.0_r8 (8/8 lines).
- Android 17: not affected (not listed by the bulletin); the patched code is present at android-security-17.0.0_r1 (8/8 lines).
Unknowns
- Which Settings screens or ServiceListing builders (setting, intent action, permission, validator) were affected in practice is not shown in the material.
- The material does not show which 'more lax' approval criteria allowed the hidden approvals to be granted.
- Whether a separate fix was applied for Android 12/12L/13 is not shown. The bulletin lists them as affected, but no commit is provided.
- Whether the reload() code on 12/12L/13 matches the pre-fix structure seen here is not shown.