Fix a user ID mismatch in IMMS#queryInputMethodServicesInternal
This is a follow up CL to our previous CL [1], which aimed to
introduce a safeguard against Binder transaction failure due to too
large payload, which is actually not something new when dealing with
InputMethodInfo [2].
Anyway, the way how the original CL attempted is to filter out APKs
that contain too many InputMethodService entries (20 entries), unless
the InputMethodService is pre-installed or already enabled, and it was
implemented as an additional step in
InputMethodManagerService#queryInputMethodServicesInternal().
The primary problem is that to get the list of enabled IME IDs, the
original CL used
InputMethodManagerService#mSettings.getEnabledInputMethodNames(),
which is valid only for the current IME user. If the query is about
another user, then we are using a wrong user's enabled IME IDs, which
is not our intention. There is, however, a secondary problem on how to
get another user's InputMethodSettings. Here is why.
Here is the boilerplate code to instantiate an InputMethodSettings
object for a given "userId".
ArrayMap<String, InputMethodInfo> methodMap = new ArrayMap<>();
ArrayList<InputMethodInfo> methodList = new ArrayList<>();
ArrayMap<String, List<InputMethodSubtype>> additionalSubtypeMap =
new ArrayMap<>();
AdditionalSubtypeUtils.load(additionalSubtypeMap, userId);
queryInputMethodServicesInternal(mContext, userId,
additionalSubtypeMap, methodMap, methodList,
directBootAwareness);
InputMethodSettings settings = new InputMethodSettings(mContext,
methodMap, userId, true /* copyOnWrite */);
With the commit in question [1], however, there is a cyclic data
dependency, that is, we need to rely on
InputMethodSettings#getEnabledInputMethodNames()
to instantiate an InputMethodSettings.
ArrayMap<String, InputMethodInfo> methodMap = new ArrayMap<>();
ArrayList<InputMethodInfo> methodList = new ArrayList<>();
ArrayMap<String, List<InputMethodSubtype>> additionalSubtypeMap =
new ArrayMap<>();
AdditionalSubtypeUtils.load(additionalSubtypeMap, userId);
queryInputMethodServicesInternal(mContext, userId,
additionalSubtypeMap, methodMap, methodList,
directBootAwareness,
// the following settings is not yet available.
// it will be created in the next line!!!
settings.getEnabledInputMethodNames());
InputMethodSettings settings = new InputMethodSettings(mContext,
methodMap, userId, true /* copyOnWrite */);
Fortunately, the real data dependency is not cyclic and we can still
create the necessary list by directly accessing
Settings.Secure.ENABLED_INPUT_METHODS.
With above, this CL introduces
InputMethodUtils#getEnabledInputMethodIdsForFiltering()
so that queryInputMethodServicesInternal() can be used without relying
on InputMethodSettings.
This CL is also a preparatoin to start maintaining multiple instances
of InputMethodSettings at the same time.
There must be no semantic change in this CL except for we now take
right user's enabled IME IDs into considerations anyway.
[1]: I51703563414192ee778f30ab57390da1c1a5ded5
eed1008252d8e2e9411c0813cc43ad4bf0fbd624
[2]: Ibb2940fcc02f3b3b51ba6bbe127d646fd7de7c45
f06569561fe1c6e898debf8bb9f37331a9f87323
Bug: 261723412
Bug: 309837937
Test: presubmit
Change-Id: Iac98fdbb2758f4d9c68930f49d219eb83e54a3d0
2 files changed