This can be used by apps that won't work without an account of that
type in the limited user environment. This way we can avoid letting
users select these apps when setting up a limited user.
Bug: 8600261
Change-Id: Iaa0dd5ff88e89fa7a1d8a4e70317290268411bdb
since SF now relies on receiving a frame for latching the
transparent region hint, we make sure we will indeed redraw
something.
Bug: 8581533
Change-Id: Ia12ddf5654a7deeac7628b799bfde4b8c16c992b
1. The event dispatch methods should respect the child drawing order.
Hover event dispatch in ViewGroup was not repsecting this order.
bug:8606799
Change-Id: Ie2fd3aff1292c21df23a04ca0aa03a97813c44ef
Avoid confusion with user restrictions which can be applied to
non-limited users as well.
Updated the java docs.
Change-Id: I4097c50b528b01a49cebcb0832d09f2b06998faa
Adding features which round out the animation APIs (missing
getters, etc.). Also fix doc typos.
Issue #8350510 Add APIs needed for future animation capabilities
Change-Id: I063736848ba26e6d6c809b15fc3a103c74222f46
1. This allows UiAutomation type tests to run as if an
android monkey test is running. This allows applications
that recognize that they are drive by a test framework and
avoid performing certain actions such as calling 911.
2. Fixed a bug where the UiAutomation#disconnect() was not
called when the instrumentation is shutdown.
bug: 8588857
Change-Id: I9e3624dfbe2b8f81f27805711de1098ea2edd03d
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
1. A dispatch event can happen as soon you call enabled,
and we won't be ready to receive it. Also add error checks
and not crash if such a thing happens.
2. Java layer shouldn't call disable on the native layer
for trigger sensors. Native layer will clean up on its own.
b/8165631
Change-Id: Icbe76bd1f50632c0bcb0b3b04975b2c2f20ff36b
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
- fix DrawableContainerState.getChangingConfigurations() to take care about its children
- make Resources.verifyPreloadConfig() return false when the changing configuration
contains layout direction bits (this is when a Drawable is having different version
for LTR and RTL layout directions)
- use constant state instead of the resource type value for checking if we can
preload the drawable
- fix typo
Change-Id: Idd64caf0fbe0f5cfd5ffe09343e84bafa9446ea5
