Emit a trace when a new dictionary is copied to LatinIME
successfully, not just when it fails. That will help diagnosing
some problems by being able to ensure this step succeeded
looking at the log.
This does not happen often (like, maybe 3 times at device
activation, and once every few weeks afterwards), so I think
the extra line in the log is more than acceptable.
Change-Id: I1674bc22d950a7be801076c5aa7e8bbebccab14b
This change also eliminates a reference of
AudioAndHapticFeedbackManager from KeyboardSwitcher and MainKeyboard.
Bug: 6522943
Change-Id: Iac42ec8ff00c66deb76a660ffc07477923a58959
This is much better interface-wise. It eliminates all blinking
of the line in the practice.
Bug: 8874148
Bug: 8864306
Change-Id: I87754e44784327c2e9c8b162d598d145e20668e8
There is no reason not to contact the dictionary provider
when we don't have internet permission or when the URL
is empty. It knows how to handle both these cases.
Bug: 9388602
Change-Id: I30c4540551ad2f5e527d3acd1842bbd749feca89
I548d899b introduced a new method to fix a sync miss between
the cursor position and the cached cursor position, but did not
take into account that it should also update the cached text
before and after the cursor in this case and that there was
already a method for doing this.
Change-Id: I31bd741893207c822827304e77791b1159774e1a
When there is only one suggestion, this code does
not work. The reason for that is, it's not homogeneous
at all and takes indices of one thing into another.
Not completely related to b/8839763, but realized
working on this and needed to have it addressed.
Bug: 8839763
Change-Id: I422730cc7eebb69ff421a171025af0390ebcdf92
in the hope of avoiding UnsatisfiedLinkError. This is definitely not a
confident fix as we still don't know the root cause of the issue.
bug: 9325110
Change-Id: I1abf8031b98509f63fce6a2d069d497895ea712c
SpannableStrings are not the only type of Spanned, they are
only the mutable kind. SpannedString is the immutable one.
Spanned is the correct class to use there.
Bug: 8839763
Bug: 8862327
Change-Id: Ic5e6199a51f22368914f2748ac2d0d1ca6a33f78
This changes how the Range class stores its data, but not its
functionality. It also improves encapsulation a bit.
Bug: 8839763
Bug: 8862327
Change-Id: I5bd583b3fc96a99b93a2632882d8fd587c03ab76
The documentation for setComposingRegion states explicitly
that it does not move the cursor. This is just a bug.
This does not have any ill effects right now, but it will have
in later changes if not fixed.
As for the selection handling, the specific test that this code
removes used to serve a purpose, but it does not any more because
the code using the value has been much sanitized. Now the variable
can just take the obvious value, and become so self-explanatory
that the comments are unnecessary.
Change-Id: I548d899b38776bd3ab5f5361aab0d89d98f12e73
As a preparation to show "system default" in the settings. LatinIME
can't know the actual system default value.
Bug: 9468462
Change-Id: I0b7898d1ca29ded7a619dd636d2ad16eb0db292e
This will spare a lot of IPC for Latin IME at the cost of very little
retained memory.
This improves the loading by potentially a lot - between 15 and 30%
when the layout is cached (which should now be the case almost every
time), and half that if it's not. More importantly, it makes the
load time less sensitive to high device load, which is one of the
sore points.
Bug: 8689779
Change-Id: I2e07736f1a92c38eed0e203bc690761a181da8b9
In setup wizard, InputMethodManager may not be able to be aware that
this IME is installed, especially just after the IME is installed via
GooglePlay app and hit the open button on the app to launch the setup
wizard.
Bug: 9299618
Change-Id: I00c8544178b41074253d49ae9481996ec56593d2
This change utilizes the no panel auto more key feature to implement
long press shift key for shift lock.
Change-Id: I3995d25dc35aea3c67b5aa29299815462eff9cad
Now that separators have their own LogUnits, they must be uncommitted
from the LogBuffer when backspacing over them.
Bug: 9088919
Change-Id: Ib36cc94939b93abe18850a06bced17caf8aaa5b9
Currently when the user reverts a batch input, a LogUnit is uncommitted
from the LogBuffer. It should not be, because the LogUnit containing the
batch input is never committed in the first place (it is only committed
to the LogBuffer when a key is pressed or a new batch input is entered).
Bug: 9088919
Change-Id: I323af453ce082437a663ccae977b21b775a964bc