CVE-2024-49736 AI-generated analysis

platform/packages/apps/Settings, factory reset UI (MainClear) / Dynamic System Updates

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.

Settings' factory reset screen (MainClear) now checks DynamicSystemManager.isInUse() before keyguard confirmation. If a Dynamic System Update image is in use, it shows an informational AlertDialog (R.string.dsu_is_running) and returns instead of continuing with the reset flow.

Root cause

In src/com/android/settings/MainClear.java, the reset handler went from its existing early-return check straight to runKeyguardConfirmation(KEYGUARD_REQUEST) and the factory reset flow. It never checked whether the device was booted into a Dynamic System Update (DSU) image. The material does not show the concrete failure mode. The bulletin classifies the result as a High severity DoS, and the fix title ("Disable factory reset in DSU mode") indicates that resetting while DynamicSystemManager.isInUse() is true is the problematic condition.

How the fix works

• src/com/android/settings/MainClear.java, in the reset handler code just before runKeyguardConfirmation(KEYGUARD_REQUEST): after the pre-existing early return, the fix gets DynamicSystemManager via getActivity().getSystemService(Context.DYNAMIC_SYSTEM_SERVICE) and calls isInUse().
• If isInUse() is true, it builds an AlertDialog with title R.string.dsu_is_running and a no-op positive button R.string.okay, shows it, and returns. runKeyguardConfirmation and the rest of the reset flow are never reached.
• New imports: android.app.AlertDialog, android.content.DialogInterface, android.os.image.DynamicSystemManager. Single-commit fix, 16 added lines, no other files changed.

Completeness

• The guard is placed only in MainClear, before keyguard confirmation. No later stage of the Settings reset flow is modified by this diff.
• The diff does not touch any factory reset entry points outside Settings. The material does not show whether those are guarded elsewhere.
• The dialog is purely informational; no persistent state or setting is changed.
• The diff references R.string.dsu_is_running but does not add it. The commit changes only MainClear.java. Where the string is defined is not shown.

Behavior changes

• When a DSU image is in use, pressing the factory reset button in Settings shows an AlertDialog titled R.string.dsu_is_running with an OK button and does nothing else. Before the fix, it proceeded to keyguard confirmation and reset.
• No change in behavior when DynamicSystemManager.isInUse() is false.
• getSystemService(Context.DYNAMIC_SYSTEM_SERVICE) is now called on every reset button press, and the result is used without a null check.

Per major

• Android 14: same fix: commit 69b3831009d1 in android-security-14.0.0_r16 (cherry-pick of 5f8f7f93f3b5, Change-Id I485eb6ac7beec0893d91ca5fe8ad88ecd96a5cbe); 8/8 patched lines present at android-security-14.0.0_r29.
• Android 15: not affected (not listed by the bulletin); the patched region is present (8/8 lines) at android-security-15.0.0_r17.
• Android 16: not affected (not listed by the bulletin); the patched region is present (8/8 lines) 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

• The concrete DoS outcome of factory resetting while a DSU is in use is not shown in the material.
• Whether other factory reset entry points (outside MainClear) have equivalent DSU guards is not shown.
• Whether R.string.dsu_is_running was added in a separate commit or already existed in Settings on each affected branch.
• The exact name and type of the listener containing the new code are not visible in the diff hunk.

Back to January 2025 · Findings