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

0 files changed, 0 insertions, 0 deletions