This patch sets up an "empty" hyphenator, which it uses by default
for locales in which there is no hyphenation pattern data. This has
the effect of enabling soft hyphens (U+00AD), which were otherwise
disabled, because the "no-hyphen" code path didn't consider them.
Bug: 19605972
Change-Id: I4dcb95cee8edc48495f7c38736f5abf26fa04935
All the necessary information (most importantly outsets) arrives in
addWindowToDisplay that is happening a few lines earlier.
Bug: 22073222
Change-Id: I483e98808877f32812c0e959cdfc14b4e0ca5e62
This reverts commit 954d1333c4.
The revert is due to apps calling super.onGeolocationPermissionsShowPrompt see b/22685046
Bug: 22685046
Change-Id: I2a9f42b432a010828a0cafaee064480bb0f91cbe
(cherry picked from commit 0bb7d2e467)
Any place that we check permissions we also need to check any
app-ops associated with those permissions. In the case of providers
with both <provider> and <path-permission> permissions, track and
report the strongest app-ops denial.
Bug: 22718722
Change-Id: I45e62de39b04d16d071558ad980b701667cfcb9a
Running status was being parsed incorrectly.
This could cause stuck notes or exceptions when sending running
status messages to a Bluetooth MIDI device.
Bug: 22689606
Change-Id: I9f7abce9758927be587eead9614617d5b0076353
Signed-off-by: Phil Burk <philburk@google.com>
When selecting text and expanding the selection, the handles snap
to the end (or start) of words. The handles don't snap until the
user has moved halfway through the word.
In horizontally scrolling text views, where some of the text is
cut off, the user cannot be halfway through the word, this causes
the selection to get stuck unless the user scrolls the view and then
continues selecting.
This CL does two things:
1) Checks if the user is close to the edge of the view when the
view can scroll horizontally, and places the cursor at next offset
if available.
2) Moves the code to check if handles are crossing into own method
this should be done each time the cursor is placed and avoids the
need to duplicate the check throughout updatePosition code.
Bug: 22657879
Change-Id: Ic14cb0994cd202a897bf6532f3832bb93ed49bfb
Basically this is a copy of Iabef96921dd554ce3768fb18619cefc
for InputMethodManagerService.
As described in JavaDoc of Intent#ACTION_SCREEN_OFF and
Intent#ACTION_SCREEN_ON, one can use those Intents to be
notified when the device becomes non-interactive and
interactive. IMMS has relied on them to enable and disable
InputConnection between the IME and the application so as not
to allow IMEs to update text when the user does not present.
This is actually our design goal as documented in JavaDoc of
InputMethodManager.
An IME can never interact with an InputConnection while
the screen is off. This is enforced by making all clients
inactive while the screen is off, and prevents bad IMEs from
driving the UI when the user can not be aware of its
behavior.
The goal of this CL is to improve the timeliness of above
mechianism by introducing a direct communication channel from
PowerManagerService to InputMethodManagerService via Notifier.
Actually this is what InputManager has been doing since
Iabef96921dd554ce3768fb18619cefc3230b5fb0.
Reasons behind this change are:
1. There are several bugreports that imply those Intents can
dispatch tens of seconds after it is enqueued. This is
indeed problematic because the user cannot type password
to unlock their devices until queued
Intent#ACTION_SCREEN_ON is dispatched. This CL addresses
such an issue without waiting for figuring out the root
cause of the delay.
2. Intent#ACTION_SCREEN_OFF and Intent#ACTION_SCREEN_ON are
sent as a ordered broadcast, which may not be suitable for
tasks that require a certain level of timeliness, and what
IMMS wants is to enable users to start typing immediately
after the system.
This CL was originally authored by Seigo Nonaka.
Bug: 22423200
Bug: 22555778
Change-Id: I747c37ff6dd8f233faef43f2b5713a4320e848eb
