CVE-2025-26444 AI-generated analysis

platform/frameworks/base, services/voiceinteraction (VoiceInteractionManagerService, assistant role handling)

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

Removes the code in VoiceInteractionManagerService's PackageMonitor.onHandleForceStop that ran when the current voice interactor package was force stopped. That code nulled the interactor and recognizer settings, reset the current assistant, re-ran initForUser and cleared the ROLE_ASSISTANT role holders (falling back to the roles.xml default). Now the service is only shut down and restarted.

Root cause

In services/voiceinteraction/java/com/android/server/voiceinteraction/VoiceInteractionManagerService.java, the anonymous PackageMonitor's onHandleForceStop(Intent, String[] packages, int uid, boolean doit) checks whether any force-stopped package equals the current interactor's package (hitInt). When hitInt && doit was true, the old code shut down mImpl and then called setCurInteractor(null, userHandle), setCurRecognizer(null, userHandle), resetCurAssistant(userHandle) and initForUser(userHandle), followed by RoleManager.clearRoleHoldersAsUser(RoleManager.ROLE_ASSISTANT, 0, UserHandle.of(userHandle), ...). The commit message says this behaviour 'seems to be accidental' and grew out of fixes for b/20882522, b/121104681 and b/124450140. The net effect was that force stopping a third-party assistant reset the default assistant (role and settings) to the fallback app set in roles.xml, instead of just restarting the service.

How the fix works

• VoiceInteractionManagerService.java: PackageMonitor.onHandleForceStop, hitInt && doit branch. The fix deletes setCurInteractor(null, userHandle), setCurRecognizer(null, userHandle), resetCurAssistant(userHandle) and initForUser(userHandle). The interactor, recognizer and assistant settings are no longer changed when the current interactor's package is force stopped.
• Same branch: the fix deletes the RoleManager.clearRoleHoldersAsUser(RoleManager.ROLE_ASSISTANT, ...) call and its failure log. The assistant role holder is no longer cleared, so it is no longer reset to the roles.xml fallback.
• Kept: unloadAllKeyphraseModels(), mImpl.shutdownLocked() plus setImplLocked(null) when mImpl != null, and switchImplementationIfNeededLocked(true). The service is still torn down and restarted, which preserves the original fix for b/20882522 (the assistant responds after a force stop). The comment now says 'restart the service'.

Completeness

• The fix covers only the hitInt && doit branch of onHandleForceStop (the current interactor package is force stopped). It is a pure deletion and adds no check on who triggered the force stop.
• The sibling hitRec && doit branch (the current recognizer, not the interactor, is force stopped) is untouched at android-security-14.0.0_r29. It still calls setCurInteractor(null, userHandle) before initRecognizer(userHandle), with a TODO saying the reason for clearing the interactor is not known.
• The separate path around lines 2329-2330 of the same class calls setCurInteractor(null, userHandle) and resetCurAssistant(userHandle) when the configured service is not valid. It is untouched, and it is a different condition from a force stop.
• According to the commit message, clearing the assistant app's data still turns off its in-app setting. That behaviour is outside the scope of this change.

Behavior changes

• Force stopping the current assistant (voice interactor) package no longer resets the assistant role or the voice interactor and recognizer settings. The user's chosen assistant stays selected.
• No RoleManager.clearRoleHoldersAsUser call is made for ROLE_ASSISTANT on force stop, so the roles.xml fallback assistant is no longer applied as a side effect.
• initForUser(userHandle) no longer runs again on force stop. Only switchImplementationIfNeededLocked(true) restarts the implementation.
• The 'Failed to clear default assistant for force stop' error log can no longer appear.

Per major

• Android 14: Same fix: commit c439c7e75e73 in android-security-14.0.0_r20, cherry-picked from ba9625e664c7 / 072de93c14f1, Change-Id I180e699bd8d3fb5ea6aa4807f435060999436416. At android-security-14.0.0_r29 the code context shows the post-fix onHandleForceStop body; the per-major facts report 6/8 lines of the patched region present.
• Android 15: Not affected: the bulletin does not list Android 15. 6/8 lines of the patched region are present at android-security-15.0.0_r17.
• Android 16: Not affected: the bulletin does not list Android 16. 6/8 lines of the patched region are present at android-security-16.0.0_r8.
• Android 17: Not affected: the bulletin does not list Android 17. 6/8 lines of the patched region are present at android-security-17.0.0_r1.

Unknowns

• The material does not show the attack surface behind the bulletin's EoP rating (which caller can trigger the force stop of the assistant package).
• The material does not show whether the two cherry-pick sources (ba9625e664c7, 072de93c14f1) differ from this commit.
• The material does not show whether the untouched setCurInteractor(null) in the hitRec branch is considered part of the same issue.
• The material does not show why only 6/8 lines of the patched region match on each branch.

Back to May 2025 · Findings