CVE-2025-48620 AI-generated analysis

platform/frameworks/base, services/voiceinteraction (VoiceInteractionManagerService)

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

Removes an early return in VoiceInteractionManagerService's package-change handler so that, when a voice interaction service is set, the code that resets the current voice recognition service on package removal is still reached.

Root cause

In VoiceInteractionManagerService.java, in the package-change handler (onSomePackagesChanged per the commit message), the block that handles a non-null curInteractor ended with an unconditional `return;`. Whenever a voice interaction service was set, the handler therefore exited before the later logic that, per the commit message, resets the current voice recognition service when its package is uninstalled. The commit's test step (check `settings get secure voice_recognition_service` after uninstalling the recognizer) indicates the setting was left pointing at the removed package.

How the fix works

• services/voiceinteraction/java/com/android/server/voiceinteraction/VoiceInteractionManagerService.java, package-change handler (onSomePackagesChanged per the commit message): the `return;` at the end of the curInteractor block is deleted, so execution continues to the rest of the method, which per the commit message includes the recognizer reset logic.
• Same file and function: the next `if (curAssistant != null)` is changed to `if (curInteractor == null && curAssistant != null)`, with a comment saying the interactor case was already checked above. The removed return used to ensure this block only ran when curInteractor was null, so the new guard keeps the assistant check as it was. Per the commit message, the recognizer reset logic later in the method is now reached in both cases; that code is not shown in the diff.
• Verification in the commit: manual. Uninstall the voice recognition app and check `adb shell settings get secure voice_recognition_service`.

Completeness

• The fix only changes control flow in the package-change handler so that the existing recognizer reset logic is reached when an interactor is set. It adds no new validation of the recognizer setting itself.
• The curAssistant check stays equivalent to the old behavior (it is only evaluated when curInteractor == null). The fix does not change what happens to the assistant when an interactor is present.
• Only the hunk around the removed return is shown. Whether the curInteractor block has other early exits before the removed return is not visible in the material.
• handleUserStop (shown in the context) only switches the implementation when the interactor package stops. It does not touch the recognizer setting and is not modified by this fix.

Behavior changes

• When a voice interaction service is set and a package change occurs, the handler now continues past the interactor handling to the recognizer reset logic. Per the commit message, uninstalling the voice recognition package now resets voice_recognition_service instead of leaving the stale value.
• No change when no interactor is set: the assistant check runs exactly as before.
• No new error codes or API changes.

Per major

• Android 14: same fix: commit 66a76238a130 in android-security-14.0.0_r24. At android-security-14.0.0_r29, 4 of 5 lines of the patched region are present.
• Android 15: same fix: commit 0925826a6ad8 in android-security-15.0.0_r12, same diff at a different line offset (~2669). At android-security-15.0.0_r17, 4 of 5 lines of the patched region are present.
• Android 16: same fix: commit db86972777c8 in android-security-16.0.0_r3, same diff at line offset ~2676. At android-security-16.0.0_r8, 4 of 5 lines of the patched region are present.
• Android 17: not affected (not listed by the bulletin). At android-security-17.0.0_r1, 4 of 5 lines of the patched region are present.

Unknowns

• The recognizer reset code that now becomes reachable is not shown in the diff or context. Its exact conditions are known only from the commit message.
• How a stale voice_recognition_service setting leads to the bulletin's EoP rating is not shown.
• Whether the method has other early exits that could still skip the reset in some cases is not visible.
• Android 13 is listed as affected, but the material has no Android 13 fix commit or code.

Back to December 2025 · Findings