It seems some applications rely on Looper.quit() terminating the
loop immediately without processing all messages. Rather than
risk breaking them, make the safer behavior optional.
Also take care to properly drain the message queue before quitting
so that all of the Message instances are recycled. This may
help release storage sooner in case the Looper doesn't get GC'd
promptly and its remaining queue of undelivered messages sticks
around.
Improve docs on runWithScissors.
Bug: 8596303
Change-Id: I8cbeb6f7a5f6b8e618b5109f87a03defc1486b9f
Accessibility services can perform special operations such as retrieve
the screen content, enable explore by touch, etc. To ensure the user
is aware that the service will perform special operations we were using
permissions. However, the special operations cannot be performed unless
the service is really enabled by the user and it is at this point that
we want to notify the user about the service capabilities.
This change adds capability attributes to the accessibility service's
meta-data XML file. The service has to declare the capability and when
it is enabled we show the user the capabilities in the warining dialog.
bug:8633951
Change-Id: Id3442dc71dad018e606888afdc40834682fdb037
This call should be analogous to calling
setHomeActionContentDescription(null) and not throw an exception.
Bug 8657256
Change-Id: Ifa9c7b999f4bf1a31fba43f869e234b1f1861512
b/8631678
1.GeofenceRequest object created.
2.MonitorState moved to a new callback
3.getTypeAndStatus separated to 2 calls.
4.Binder death implemented
5.geofenceChange callback name changed.
6.Parameters rearranged in some calls.
Change-Id: I8fe9621186aeb49efeb0eef1821a2556afe03cfc
Use a Bundle for persisting and passing to the application, but use a
list to return data back from an application that's exposing restrictions.
Changed the xml reading/writing code to store the value type in the Bundle
so that it can be reproduced when reading. Earlier we were assuming only
String and String[].
Bug: 8633967
Change-Id: I523d5553728edcf28a1e9d432f490b4956f34215
The invalidate region when the clip bounds are set needs to encompass both
the old clip bounds and the new bounds, to make sure that the right area
of the view gets erased as well as drawn.
Also, we need to keep our own internal copy of the bounds, not just use the
instance passed into the setter.
Issue #8634060 setClipBounds() problems
Change-Id: I123c49cff16e3debe8866974a5612a4efd010de4
Push the interface methods from the new Animatable interface back
down into Animator, from whence they came.
Issue #8634310 Remove Animatable interface
Change-Id: I79e26001709d791d54fcb02561640fe2e008b1fd
- in AbsListView, force setScrollbarPosition() when RTL properties change
- in FastScroller, invalidate the correct rectangle when in RTL mode and in STATE_EXIT
Change-Id: Ie9fe4f826e179eb993e443d10e171b9dda3b6f3f
This change disables all atrace tracing in Zygote immediately after it is
initialized. This is necessary because Zygote has no way to receive
notifications that the enabled trace tags have been changed. Tracing is
re-enabled when other processes fork from Zygote.
Change-Id: If2983858fb0c4890ba9ab041849b1c4d98f66c13
Adding a view to an overlay usually entails removing the
view from its current parent, if it has one. ViewOverlay.add() will
do this automatically. At the same time, it will check to see whether
the parent view is in a different global location than the overlay's
host view, and will adjust the added view accordingly. This enables
the caller to simply toss a view into an overlay and have it end up
at the same global position on the screen.
the problem is that the current code doesn't bother to check whether
the old parent is attached. If that parent has been removed from the
view hierarchy before this overlay operation, then it will show up as
being at (0,0) in the window, not its old location. This results in the
view being mis-positioned in the overaly.
Fix is simple: if the view's old parent is not attached, simply remove
it from that parent before adding it to the overlay; don't try to compensate
for its position which is based on wrong information.
Issue #8620319 Overlay should only use relative window locations for onscreen parents
Change-Id: I414038a6c355dfd58f9766b007ac44d535ef1889
