Drawables added to a view's Overlay will now cause the Overlay to
be invalidated via the normal drawable-invalidation mechanism. That is,
changes to any of the drawables in the overlay should cause invalidation of
the proper area of the overlay and thus the hostView, causing the appropriate
area to be redrawn.
Also, fixed a bug in drawable invalidation so that bounds changes will now
correctly invalidate both the old and new bounds areas.
Issue #8350510 Add APIs needed for future animation capabilities
Change-Id: Icae5fa0e420232ee17dc39be10084345bae8dbd8
- remove the ICU related methods and update the methods using the "reserved" argument
- update to CTS in another CL too
Change-Id: I5509736568c342d9d17bfeafc17951117ab5d3cc
To support the WiFi service, we need to support migration from the
system UID to the wifi UID. This adds a command to achieve the
migration.
Bug: 8122243
Change-Id: I65f7a91504c1d2a2aac22b9c3051adffd28d66c1
In previous commits, we added the ability to specify which UID we want to
target on certain operations. This commit adds the ability to reach those
binder calls from the KeyStore class.
Also fix a problem where saw() was not reading all the values returned via
the Binder call. This changes the semantics to return a null instead of
failing silently when it's not possible to search.
Change-Id: I32098dc0eb42e09ace89f6b7455766842a72e9f4
If ViewRootImpl throws BadTokenException when adding a window, clear
the indication that a window has been added. That way when the
window is destroyed it doesn't try to clean it up.
Fixes bug 8409506.
Change-Id: I270740762f21ed4ec7f235344a3adaeaa033c483
If ViewRootImpl throws BadTokenException when adding a window, clear
the indication that a window has been added. That way when the
window is destroyed it doesn't try to clean it up.
Fixes bug 8409506.
Change-Id: I270740762f21ed4ec7f235344a3adaeaa033c483
it's still incorrect to use Surface from different
threads, however this shouldn't result to native crashes
anymore.
Bug: 8328715
Change-Id: I89ac5cc1218dc5aa0e35f8e6d4737879a442f0c6
- fix start/override mechanism
- take care of RTL compatibility mode (pre JB-MR1)
- fix where reset of drawables resolution needs to happen
Change-Id: I55a69487a0eedee14c4be7006ee0abad085200ad
This is the other part of a fix with transient state. A layout container
may be out of sync with its adapter during a data change. When the transient
state views are managed by their positions, and these positions may not match
between the container and the adapter, then the views will not be updated
correctly on the screen (though the underlying data will still be correct).
An earlier fix addressed the problem when the adapter has stable IDs (managing
the transient views by their IDs instead of their positions). This fix addresses
the other part of the problem, simply avoiding managing via positions during
a data change.
Issue #8254775 View.setHasTransient state has side-effects when deleting content in ListView
Change-Id: I0fe1692a1507a042180f8a14a8ef2d0c6946a061
ListView child views with transientState (setHasTransientState(true)) are not
handled correctly when the data set changes, such as when an item is added
or removed. The problem is that the transient views are cached by their
position, but this position is out of sync between the ListView and the adapter
until the ListView layout process is complete.
A better way, which unfortunately only works on ListViews with stable IDs, is
to cache the views by their itemID instead, and to use that ID to determine when
and where to reuse/retrieve a transient view during the ListView layout.
Issue #8254775 View.setHasTransient state has side-effects when deleting content in ListView
Change-Id: I2fc25e71ed6655af30b9c3f47fdf014e9b667616
