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
Anyway they need to request account access and user will be asked to approve access to the account
at runtime.
Bug: 8617168
Change-Id: I31de852b9bb25f496becc3e6470265b5c330e6ad
This covers all useful data from the basic Builder as well
as each of the Styles that is not otherwise captured on the
Notification object itself.
Extras are now prettyprinted in dump() output.
Bug: 8270485
Change-Id: I47fc50860dab6409793f57e904cc60296310d5cf
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
