Move 3 IMMS utility classes to services.jar
Short summary:
There is no need to have these 3 utility classes in frameworks.jar,
because these classes are used only from InputMethodManagerService
(IMMS) and its utility classes. We should move them to services.jar.
Long summary:
* InputMethodSubtypeSwitchingController
This class was mistakenly placed in the current Java package since its
beginning [1]. This class is purely a state machine that is designed
to be used only from IMMS hence there has been no way for app
processes to use this class in a meaningful way.
* LocaleUtils
This class was also mistakenly placed in the current Java package
since its beginning [2]. This class is purely a state machine that is
designed to be used only from IMMS hence there has been no way for app
processes to use this class in a meaningful way.
* InputMethodUtils
The situation of InputMethodUtils is a bit different. It was
introduced in the right place actually [3], because the original
purpose of this class was to share some utility methods between IMMS
and the Settings application. For that purpose, having this class
under frameworks/base/core/java instead of frameworks/base/services/
totally made sense.
What was unfortunate is that we have kept adding more and more utility
methods into InputMethodUtils since then, even though most of methods
have been used only from IMMS. To make things worse, more and more
random components started depending on this utility class. When we
realized it, we were in the situation where we could not even easily
refactor methods in InputMethodUtils without updating a bunch of
call-sites across repositories, including multiple platform-specific
Settings app and SetupWizards.
This is basically why I decided to stop allowing Settings apps and
SetupWizard to use InputMethodUtils, and decided to let them depend on
SettingsLib [4] instead. After many cleanup CLs [5], we have finally
achieved the state where InputMethodUtils is used only from the system
server process.
* A special bonus
With my previous CL [6], we can even make these 3 utility classes
package-private, which guarantees that only IMMS and its utility
classes directly depends on these utility classes.
* Risk
Now that this is purely a mechanical refactoring of an implementation
detail within frameworks/base, there should be no observable behavior
difference.
[1]: I11ed9a767588f8080753cd9bce011dac7db579ad
d7443c83ceae0bdd20d68bf84648cf3b40115d85
[2]: I315cf3722a06e00bdbfac284c4949578da8fe78d
102ff0726dad764df741e41766d78fcfb829184a
[3]: I0bc9954f163a3ec38d08b9ba842a8a31176eb6a6
8e303cc5dd4860b6050d5725ce60ca7e6fb00c7b
[4]: frameworks/base/packages/SettingsLib
[5]: CLs that have Bug 77730201 in their commit messages
[6]: I023d8f2863601ee54f304988117d8ea750770f70
603f4d00c613c464f2ce5b6a831dda811dbf5138
Bug: 77730201
Bug: 114660660
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Test: atest FrameworksCoreTests:com.android.internal.inputmethod
Test: atest FrameworksServicesTests:com.android.server.inputmethod
Change-Id: I37594096151d77adb6741a41d7985a4506f96ccb
7 files changed