In single line mode, changing the text from LTR to RTL (or vice versa)
affects the alignment, which in turn means that bringTextIntoView is
needed to update the scrolling. A registerForPredraw should be done to
make this happen, but it was missing. This patch tests explicitly for
direction changes in this case, and schedules a predraw if so.
Change-Id: I16e0e23141c244dc8adc00ea8306dfe4c9bf487d
Fixes issues brought in by change to isHostRoute. isHostRoute
was technically correct, but the callers really wanted hasNextHop
behavior.
bug:8597268
Change-Id: I360761ccfa98b2ba34642f717a78fa71ec1bae4f
A bug in FolderEditText or DynamicLayout (b/8600683) was causing
the 'rectangle' parameter passed to scrollToRectOrFocus() to be
roughly 1000 feet to the right of the screen.
This bug is normally masked because the focus found in
mLastScrolledFocus never matches the new focus and consequently
the misleading 'rectangle' is nulled. However, on the first
time in to scrollToRectOrFocus when returning to Launcher
from another app, mLastScrolledFocus is null and the code
skips over the place where 'rectangle' is nulled. Without this
clearing it was determined that 'rectangle' was outside the viewable
area and scrolling not required. This is bug 8547155.
This change causes even null values of mLastScrollFocus to be
compared to the new focus thus masking the bug in all situations.
Bug 8600683 will be fixed in a separate CL.
Fixes bug 8547155.
Change-Id: Ic6cb22c42b0e93a9793dd2babc25727c2ba29155
ActivityThread.currentPackageName() was actually returning
the process name. Change this to return the package name, and
fix the one spot using it I could find that was actually wanting
the process name.
Change-Id: I323b9c5987106b5a090968e545281fc0ba55b6b8
...to allow for orientation locking
This doesn't add an API to get the current orientation, since that is
inherantly racy. Instead there is a new "locked" orientation mode that
locks the screen into whatever the current rotation is.
While at it, added a few other useful orientation modes.
Change-Id: I5c369e6511cb72294e9e922ea8acffd770df9440
Created constants in current.txt and UserManager.java, modified restrictions access in UserManagerService.java.
Change-Id: If8d778d84af81dcbf5784f6e0afd9ef966cc8ecf
Now that we have gestures which are detected by the system and
interpreted by an accessibility service, there is an inconsistent
behavior between using the gestures and the keyboard. Some devices
have both. Therefore, an accessibility service should be able to
interpret keys in addition to gestures to provide consistent user
experience. Now an accessibility service can expose shortcuts for
each gestural action.
This change adds APIs for an accessibility service to observe and
intercept at will key events before they are dispatched to the
rest of the system. The service can return true or false from its
onKeyEvent to either consume the event or to let it be delivered
to the rest of the system. However, the service will *not* be
able to inject key events or modify the observed ones.
Previous ideas of allowing the service to say it "tracks" the event
so the latter is not delivered to the system until a subsequent
event is either "handled" or "not handled" will not work. If the
service tracks a key but no other key is pressed essentially this
key is not delivered to the app and at potentially much later point
this stashed event will be delivered in maybe a completely different
context.The correct way of implementing shortcuts is a combination
of modifier keys plus some other key/key sequence. Key events already
contain information about which modifier keys are down as well as
the service can track them as well.
bug:8088812
Change-Id: I81ba9a7de9f19ca6662661f27fdc852323e38c00
