CVE-2025-48536 AI-generated analysis

platform/packages/apps/Settings, Settings Slices (SettingsSliceProvider)

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

SettingsSliceProvider.grantAllowlistedPackagePermissions now combines the existing slice allowlist (slice_allowlist_package_names) with a new debug-only array (slice_allowlist_package_names_for_dev) whose entries are granted only when Build.IS_DEBUGGABLE is true, so packages listed only in the dev array no longer get Settings slice permissions on non-debuggable builds.

Root cause

In src/com/android/settings/slices/SettingsSliceProvider.java, grantAllowlistedPackagePermissions(Context, List<Uri>) read a single resource array R.array.slice_allowlist_package_names and, for every descendant slice Uri, called SliceManager.grantSlicePermission(toPackage, descendant) for every listed package name. It made no distinction between packages needed in production and packages only used for debugging, so every package name in the allowlist (the AOSP default is empty; entries come from overlays) was granted access to the Settings slice URIs on all build types. Per index search, SliceManagerService.grantSlicePermission checks the caller and the URI owner, then records the grant for toPkg by name via mPermissions.grantSliceAccess. The material does not show any check that toPkg is installed or trusted. The commit title describes the problem as the provider granting access to "unused packages".

How the fix works

• res/values/config.xml: adds a new empty string-array resource slice_allowlist_package_names_for_dev, documented as the allowlist for slice uri access 'for debugging purpose', next to the existing slice_allowlist_package_names.
• src/com/android/settings/slices/SettingsSliceProvider.java:grantAllowlistedPackagePermissions: builds a List<String> allowlist from slice_allowlist_package_names (added only if the array is non-null). Only if Build.IS_DEBUGGABLE is true does it append the entries of slice_allowlist_package_names_for_dev (also null-checked). If the combined list is empty it logs and returns. Otherwise it loops over descendants x allowlist and calls sliceManager.grantSlicePermission(toPackage, descendant) as before. Adds the android.os.Build import.
• tests/robotests/res/values-mcc998/config.xml and values-mcc999/config.xml: add the new array (empty for mcc998; one entry, com.android.settings.slice_allowlist_package_dev, for mcc999) so the robolectric tests can exercise both paths.
• tests/robotests/src/com/android/settings/slices/SettingsSliceProviderTest.java: the existing test grantAllowlistedPackagePermissions_hasPackageAllowlist_shouldGrant now forces IS_DEBUGGABLE=false and verifies the dev package is never granted. The new test grantAllowlistedPackagePermissions_hasPackageAllowlistAndDebuggable_shouldGrant forces IS_DEBUGGABLE=true and verifies the dev package is granted. On Android 14 this uses ReflectionHelpers.setStaticField(Build.class, "IS_DEBUGGABLE", ...); on 15/16 it uses ShadowBuild.setDebuggable(...).

Completeness

• The commit adds the gating mechanism only. In AOSP both arrays are empty and the commit contains no overlay change. Whether overlays that populate slice_allowlist_package_names had to move entries into the dev array is not shown.
• Packages that stay in slice_allowlist_package_names are still granted access to every descendant slice Uri on all build types. The fix adds no check that an allowlisted package is installed and no validation of the target package's identity.
• On debuggable builds the dev packages are granted in addition to the production list. The gating depends only on Build.IS_DEBUGGABLE.
• The diff does not revoke grants made before the update. The material does not show whether SliceManagerService grants persist across the update.
• Only grantAllowlistedPackagePermissions is changed; the diff touches no other grant path in SettingsSliceProvider.

Behavior changes

• New resource string-array slice_allowlist_package_names_for_dev, available to device overlays.
• On non-debuggable builds, package names listed only in slice_allowlist_package_names_for_dev are never granted slice permissions. On debuggable builds they are granted in addition to slice_allowlist_package_names.
• The 'Allowlisting %d uris to %d pkgs.' log now reports the combined list size, and the 'No packages to allowlist' early return triggers only when the combined list is empty.

Per major

• Android 14: same fix: commit b1fdab0d0065 in android-security-14.0.0_r24; the test uses ReflectionHelpers.setStaticField on Build.IS_DEBUGGABLE; 8/8 patched lines present at android-security-14.0.0_r29.
• Android 15: same fix (11b11215aa18 in android-security-15.0.0_r12); identical production code change, test adapted to ShadowBuild.setDebuggable; 8/8 lines present at android-security-15.0.0_r17.
• Android 16: same fix (586f8dedd8e0 in android-security-16.0.0_r3); identical production code change, test uses ShadowBuild.setDebuggable; 8/8 lines present at android-security-16.0.0_r8.
• Android 17: not affected (not listed by the bulletin); the patched region is present (8/8 lines) at android-security-17.0.0_r1.

Unknowns

• Which package names were in device overlays of slice_allowlist_package_names and counted as 'unused'; no overlay changes are in the material.
• Whether existing slice grants persist across the update and need separate revocation.
• The exact runtime caller and timing of grantAllowlistedPackagePermissions.
• Why Android 17 is not listed by the bulletin; the material does not say.

Back to December 2025 · Findings