InputMethodAndLanguageSettings calls InputMethodAndSubtypeUtil for no
good reason. The page does not display or provide ways to change IMEs.
The virtualKeyboardFragment does, and it already contains logic for
refreshing InputMethodAndSubtypeUtil.
Bug: 32642706
Test: Compiles
Change-Id: Icdbf9cd2fa95ba3037c1e47d62c7514376cf8037
- Removed unused preferences that are commented out in pref xml.
- Also removed code that references to them in Fragment.
Bug: 32637613
Test: compile/manual
Change-Id: I84be24f9c5df7531843f03b047a93f9aa912432e
- The prefrence is not used in code according to comment, and it's not
defined in xml. So this chunk of code is redundant and should be
removed.
Bug: 32642706
Test: compiles, and manually navigate to fragment.
Change-Id: Iac38632d090c635f324bc4eed8e1c41300ddb08e
Refactored getLocaleNames() into a FeatureProvider interface so it's
reusable and testable.
Bug: 31801428
Test: RunSettingsRoboTests
Change-Id: I2d31a66a4b32cfa7a364a4cfef1f6eea87084577
When adding/editing a word for your personal dictionary
rotating the screen could cause the language to change
back to the device default. This has been fixed.
Test: ag/1389633, robolectric not supported in this branch.
Bug: 30874931
Change-Id: I0c8ebec5f4d5e7b23112b656c482c3b2cda7791f
Bug: 30681771
Test: SettingsUnitTests
Refactor visibility logging from InstrumentedFragment into a mixin. And
apply mixin in remaining fragments.
Change-Id: Ibbb59904336254a3e4bb9e8c7d0b36e5a6bc2622
This is a small follow up CL to the previous CL [1] that added
functionality to show a warning dialog when Direct Boot unaware apps and
IMEs are being selected.
In the previous CL, we checked whether the package to which the IME
belogs to is (fully or partially) Direct Boot aware. If the package is
partially Direct Boot aware but the InputMethodService in question is
still Direct Boot unaware, the user will not see the warning dialog.
Luckily in InputMethodPreference we already have InputMethodInfo that
indirectly exposes ServiceInfo#directBootAware. By directly checking
that bit we can simplify the logic and avoid such false negatives.
[1]: I0498904d2f664fb41e8c1e6bb30d1cbf437cf4b9
4a8136b51b
Bug: 27196876
Change-Id: I869a7bd87748f09f7032a60b34ac0dbdc4a00b72
Certain apps like Phone, SMS, Emergency Info, and IME are critical
enough that they ideally need to be runnable before the device is
unlocked after a reboot. Users can still pick non-Direct Boot aware
apps, but this change now warns users that the selected app won't be
runnable until after unlocking.
Bug: 27196876
Change-Id: I0498904d2f664fb41e8c1e6bb30d1cbf437cf4b9
The OnPreferenceChangeListener for the preference to show
the virtual keyboard was returning false, indicating that the
new preference was not to be persisted, even though it was
persisting the setting. That caused the accessibility
framework not to be informed of the new value, which led
TalkBack to speak the old value rather than the new one.
Bug: 30140972
Change-Id: I02b7dc1db52cb7646650e6f2e49a1e15c2233897
Settings.Secure.SHOW_IME_WITH_HARD_KEYBOARD is a per-user settings.
PhysicalKeyboardFragment needs to use the current user's ID rather than
hard-coded user ID 0.
Bug: 29406181
Change-Id: Ie40f729f3c85e9ce9ad8f957caba338786b119d9
It turns out that out previous CL [1] is not sufficient to address all
the requests regarding capitalization.
With [1], now InputMethodSubtype#getLocaleDisplayName() returns a locale
name whose capitalization is basically optimized to be used as a list
item. It works well for list UI, but on a UI element that looks like a
sentence text, we still need to capitalize the first character.
This CL takes care of those UI elements in the Settings app. This CL
also addresses a remaining TODO about locale-unaware text formatting by
using about android.icu.text.ListFormatter.
[1]: If105082ce703db7a86738455db7e9fb37f3c6fe8
e489baf96df2837a3a63b626d9023a4a8b322c28
Bug: 29035638
Change-Id: I59f93f0bc067cdd87c6065c972a7da3cde1128f9
In order to avoid layering violation, LocaleList needs to be moved from
android.util package to android.os package [1]. This CL follows up that
package change.
No behavior change is intended.
[1]: Ia8de2ee9df3dd0a42b1fe84574439519b680fe18
Bug: 28819696
Change-Id: Ibd7934b30062046830d63f33d1c6febef32da976
Bug: 26946312
Fixed in the following screens:
Apps > Gear > Special Access > Modify system settings
Apps > Gear > Special Access > Draw over other apps
Apps > Gear > Special Access > Apps with usage access
Language & input > Personal dictionary
Wireless & networks (More) > Android Beam
Change-Id: I0b9bd6c19f710302625dd87989e9d4ce3c96a9a2
In this situation onLoadFinished callback is triggered before the
loader ids list is updated. Updated the loader ids list before
triggering the loader.
Bug: 28182232
Change-Id: I1e4035f4dcff33e6b9a42d448303e962bd87c14b
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
Without this CL, preference for enabling spell checking is disabled
when spell checking is disabled.
This issue makes it impossible to re-enable spell checking from the
settings UI.
This was introduced in I0ed71bbb580e3547d97e321799ac2b77b1f284a3
that fixes Bug: 26685795.
Bug: 28157871
Change-Id: I386baf2dd79347c1202f885a3f749aea3fb6a58d
With this CL, AvailableVirtualKeyboardFragment searches icon resource in
the following order, which makes it easier to find a certain IME when
one APK contains multiple IMEs.
1. Service Logo
2. Service Icon
3. Application Logo
4. Application Icon
Bug: 28204635
Change-Id: I406ccc0d53e6ec69793c2fc8be8c6c1c90b34811
"Use system languages" is always displayed independent from the
selected value.
This happens due to inverted if-condition that has been introduced in
I0ed71bbb580e3547d97e321799ac2b77b1f284a3
Bug: 28204608
Change-Id: I9f0390242cb5ed4960c06eb3d0a4ade7a66143a5
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
InputMethodAndSubtypeUtil#saveInputMethodSubtypeList() has a bug that
it saves implicitly enabled subtypes when "Use system languages" is
checked. Implicitly enabled subtypes are transient data and the system
should have only a null data (0) in the persistent strage. The root
cause of this bug is that the method in question has not checked whether
the preference item is in enabled (not grayed-out). If it is
grayed-out, its checked state does not mean that the user manually
checked that subtype but it is just an indicator for the user.
The strange UI jank when dismissing InputMethodAndSubtypeEnabler is one
of the victim of the above bug because we have worked around it by
actually changing checked state before calling the method in question.
With this CL we no longer need to update preference items in
InputMethodAndSubtypeEnabler#onPause().
Bug: 27867966
Change-Id: Ifc291d77ea41a988438765b9ba16bc5d18a15e1b
