Do not disable IMEs upon force-stop
This is a follow up to my previous CL [1], which aimed to fix
Bug 27859687 without changing any other behavior but
unintentionally changed the observable behavior when a currently
enabled IME is force-stopped.
What would happen when a currently enabled IME is force-stopped has
never been protected with any end-to-end test, but here is a brief
history.
- Feb 22, 2010 [2]
It is also when Dianne introduced PackageMonitor class. At that time
InputMethodSettings will be updated in the following order upon
force-stopping an IME package.
1. if selected then unselect it then reset it to the most appricable
IME.
2. if enabled then disable it.
This behavior was, however, not super obvious because at that time
IMMS did not verify whether the currently selected IME is enabled or
not when selecting it. This means that IMMS continues using the
force-stopped IME as long as it remains to be the currently selected
IME at the step 1.
Note that IMMS did not support multi-user at that time. Thus no
semantics was defined about what would happen when an enabled IME was
force-stopped for a background user.
- Sep 26, 2012 [3]
The initial multi-user support was introduced for IMMS. At that time
the observable behavior is that IMMS did nothing when an enabled IME
for a background user was force-stopped.
* Current user
1. if selected then unselect it then reset it to the most
appricable IME.
2. if enabled then disable it.
* Background users
1. do nothing.
- Feb 17, 2016 [4]
While working on direct-boot support in IMMS, I introduced a new logic
to make sure that at least one non-auxiliary IME is enabled. This
slightly changed the force-stopping scenario as follows.
* Current user
1. if selected then unselect it then reset it to the most
appricable IME.
2. if enabled then disable it.
3. make sure at least one non-auxiliary IME is enabled.
* Background users
1. do nothing.
- Feb 22, 2017 [5]
At that time when I introduced an optimization around
InputMethodManagerService.MyPackageMonitor
there was an unintentional behavior change. As a result enabled IMEs
would no longer be temporarily removed from the enabled IME list. The
root cause was that I forgot to update
MyPackageMonitor#mChangedPackages
in
MyPackageMonitor#onHandleForceStop().
This unexpected behavior change has, however, never been noticed. The
force-stopping behavior had changed as follows.
* Current user
1. if selected then unselect it then reset it to the most
appricable IME.
* Background users
1. do nothing.
- Feb 09, 2023 [6]
At that time we finally addressed an issue where the current IME could
switch to any IME, even if it was not enabled. This change itself did
not change any observable behavior around force-stop because of my
previous CL [4].
- Feb 29, 2024 [1]
With my CL, the behavior became an mixture of above ones, that is,
IMMS disables the currently selected IME and IMMS refuses to continue
using the selected IME that is not enabled any more.
* Current user
1. if selected then unselect it then reset it to the most
appricable IME.
2. if enabled then disable it.
* Background users
1. do nothing.
This is how Bug 333798837 became noticeable.
- This CL
With this CL, we actually switch back to the one revision prior
behavior where IMMS does not remove force-stopped IME from the enabled
IME list.
* Current user
1. if selected then unselect it then reset it to the most
appricable IME.
* Background users
1. do nothing.
Rationals are:
- That's what we have been using since Android O. We don't want to
introduce any drastic observable behavior change unless it's
necessary.
- That's also what we have been using for any background user.
We also finally introduce end-to-end tests [7].
[1]: I10aa547f0de607ef3c0ba26764dac0585c40c843
2501e749abb30ce745f22ae33869cfb11200f37d
[2]: 21f1bd17b2dfe361acbb28453b3f3b1a110932fa
[3]: Ib23849d352db33f0747aa9d5a178f00ac726c13b
4e1ab15b305aac26ad8819fc3b2951e20985944d
[4]: Ibd53ef8db7afcfac681b401912876d2a52c743d5
859df05cc081f9390c3c0f4e816b39a8aadd8fd7
[5]: I063688297156188f68fe0b55a46d72f2e811dc88
5e3e8a5205f5ed584ad9466746f6fa397f293476
[6]: I12829de9fa58610a7d53e4b154e1550f0f791e75
55f6a873458b72b99364d531e9e0cd54236f1cc1
[7]: If7dd75a23310acc82a9ed2acf169d4c3b7ca47b7
Bug: 322062773
Fix: 333798837
Test: atest CtsInputMethodInstallTestCases:ForceStopTest
Change-Id: I261e1c60050ee20f7673425f75588269f865ba50
1 file changed