diff options
| author | 2023-04-27 13:30:34 +0000 | |
|---|---|---|
| committer | 2025-03-13 12:29:02 -0700 | |
| commit | 145b038cecd1978eea81654046e398e9920bb911 (patch) | |
| tree | a8319442bbdee1a9c5781df2fd126e26028cdbbd /cmds/bootanimation/BootAnimation.cpp | |
| parent | 73d29c73825f95985a63133a1ee48f8fe95585a3 (diff) | |
[vims] better handle assistant force stop
Currently, force stopping a 3p assistant app resets it to the default a
ssistant. This is not a desirable user experience. This seems to be
accidental, some history that I was able to dig up:
* b/20882522 - "clearing data in assistant causes it to die and not
respond to queries" - this will happen today anyway, because the
in-app setting for it gets turned off
* the fix for the above ended up resetting the assistant setting when
the assistant is force stopped (as a proxy for data cleared)
* this caused b/121104681 - force stopping assistant resets the default
assistant setting
* also b/124450140 - clearing assistant resets default to none
* the fixes for these included clearing the assistant role profile,
which ends up setting it to the "fallback" app (set in roles.xml).
This fix removes any role and setting clearing / resetting when force
stopping or clearing the active assistant app. It keeps the part that
ensures the service is restarted, i.e. the original bug is still fixed,
i.e. assistant responds to queries after being force stopped (but not
cleared, which has never worked anyway).
Fixes: 191743558
Test: atest CtsVoiceInteractionTestCases
(cherry picked from https://googleplex-android-review.googlesource.com/q/commit:ba9625e664c76943448ce5b7d97e3b381e71710d)
Merged-In: I180e699bd8d3fb5ea6aa4807f435060999436416
Change-Id: I180e699bd8d3fb5ea6aa4807f435060999436416
Diffstat (limited to 'cmds/bootanimation/BootAnimation.cpp')
0 files changed, 0 insertions, 0 deletions