With a Framework-side change [1],
InputManager#{get, set}KeyboardLayoutForInputDevice() are now able to
deal with null InputMethodSubtype as a valid input. With this CL, we no
longer filter out IMEs that do not support subtypes in
PhysicalKeyboardFragment.
[1]: Ia013784a594ad3beaf30976d047f5ac0fa8185be
Bug: 28182650
Change-Id: I46b9c5b018f08e3eaa4614a0893db0be91652f3c
This patch loads all physical keyboards at once and only updates the
screen after that returns. Previously, each keyboard's data was
loaded individually and the screen was updated for each keyboard
when the data was received.
Bug: 27549590
Change-Id: I05d80d74df14fb7bfaa0ce76a1f8919889865108
The root cause of crash bug #27749932 is that the state mismatch between
when a Loader is created and when the Loader object finishes background
task. We can easily reproduce this crash by:
1. Pair two hardware keyboard A and B.
2. Open Physical Keyboard settings.
3. Press the power button to turn off the display.
4. Move keyboard A far away so that it is unpaired.
5. Press the power button to turn on the display.
6. Unlock the device.
One of the reasons PhysicalKeyboardFragment was unstable is that loader
ID reuse. PhysicalKeyboardFragment starts background data loading
because of many events such as #onResume() and #onInputDeviceAdded() but
there are chances that loader ID was reused because we specified
hardware keyboard device index as the loader ID. This was dangerous
also because device index can change when a device is added and removed.
With his CL each loader object has an unique ID and
PhysicalKeyboardFragment keeps tracking the list of active Loader IDs
only from which PhysicalKeyboardFragment should accept data.
Also, this CL removes dependencies on PhysicalKeyboardFragment from each
loader object so that we can have a clear boundary of responsibility
between data loader and data consumer.
Bug: 27749932
Change-Id: I53fcb2426d028a492c775bb2b4ec6a5419e33bb4
This is a follow up CL to my previous CL [1], which added a new
constructor to InputMethodSettings to support File-Based
Encryption (FBE).
Settings app is the only remaining package that depends on the previous
constructor. To completely deprecate the previous one, this CL lets the
caller switch to the new constructor.
Note that this CL does not change the initial parameters of
InputMethodSettings. In other words this is a mechanical code
clean-up.
[1] I9c6f9bb3d51174198e5f73588637f87ea0d90e11
5db2f16f15549c490c9541602a96f42bef984acb
Bug: 26279466
Change-Id: I09cba4066b95c4a9e89a3e4f83d75b97882502dc
Implements selection of keyboard layouts using the new InputManager
methods that associate keyboard layouts to
device/InputMethodInfo/InputMethodSubtype
See: Ie88ce1ab77dbfe03ab51d89c1dc9e0a7ddbb3216
Bug: 25752812
Change-Id: Ib76880d66391ca37978054de80f4b3b5147cecc3
1. Introduces new UI components as per the new flow
2. Temporarily disables components in the old flow that are to be
replaced by the new flow. This is done so we can neatly revert
to the old flow if there are issues with the new flow
3. AvailableVirtualKeyboardActivity now responds to
android.settings.INPUT_METHOD_SETTINGS intents instead of
InputMethodAndLanguageSettingsActivity
Bug: 25752812
Change-Id: I728d7ee185827ed328c16cb7abce244557a26518
