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
It is useful, particularly in animations, to be able to add a view, or at
least some graphics, on top of a view. For example, to have a child of a layout
fade away, we might want to remove the child from that layout and then fade it out
gradually. Meanwhile, we have to have a place to put that view where it will be
drawn. We could do this in the content container sometimes, but this is not a
reliable workaround in the general case, and may obscure other siblings/parents of
the layout/view in the hierarchy. A better approach would be to place a view/graphic
temporarily in the layout itself.
This feature adds the ability to add one or more Views and Drawables to an "overlay"
layer, after which the view will handle drawing that extra content when it redraws itself.
Issue #8350510 Add APIs needed for future animation capabilities
Change-Id: I70bf78c46ee3db8bd87ea1cdc2ecb5c0747ccbf9
Seeking an animation after the animator has reverse()'d to the beginning
will result in seeking in reverse. Starting the animation will make it proceed
normally, and calling reverse() will also give expected behavior. But seeking
causes this unexpected behavior because the state of reversing is not reset until
the next time the animation is played (either by start() or reverse()).
Fix is to reset the internal flag when the animator ends.
Issue #8234676 Reversing an Animator Leaves it in A Reversed State Until Explicitly Started
Change-Id: I9d212ae1879aa277d1add7eb4c7ec61432af059e
BadTokenException is a normal consequence of swapping IMEs while there
is a DO_SHOW_SOFT_INPUT message in the IIMethodWrapper queue. This
race condition cannot be avoided without an unacceptable lock down of
InputMethodManagerService.
Fixes bug 8387663.
Fixes bug 8263462.
Change-Id: I2c21573cf972145ab08e66604cdb9344139a3f31
If AsyncTaskLoader starts a background update due to a
content change, and that update is cancelled, we drop the
data when it finally arrives and forget that the content changed.
If we later come back to the loader, we then end up showing
stale data because we don't know that we still need to update
due to the old content change.
This change adds a couple new APIs to Loader to deal with the
time between when you ask for whether there is a content change
and finally either commit the data or cancel the update.
AsyncTaskLoader is changed to make use of this so that it doesn't
lose changes.
Change-Id: I3866236b1c22bb9138f2d9f6032b126aeaee2e6e
Supports both age and count based constraints. Added light docs and
tests to verify behavior.
Bug: 8387555
Change-Id: If4d0dac8bc54ce705c2a339bc09a60ea748728b8
Modify WifiService to add a controller to track the various
desired states and let the WifiStatemachine actually control
the bring up.
Bug: 8141918
Change-Id: I6e98fd5a29b43c3c50c315eff5255cd0a3eaebcd
When a new IME is attached it is not enough to remove the
WindowManager messages from the local queue, but the ones in
the previous IME queue must also be removed.
Fixes bug 8263462.
Change-Id: I9e916c6052a83dc7691bcba0b6ab8328b9b7cc36
In general, calling requestLayout() during layout is a Bad Idea.
However, ListView does this during the normal course of its layout, as it
removes and adds views during layout. However, it handles this properly,
ensuring that the views in its hierarchy are all measured and laid out
properly by the time its layout process is done.
A previous fix to the request-during-layout issue attempted to distinguish
the correct from incorrect behavior by checking whether views had been properly
laid out since the requestLayout() call, and making sure the views were
visible in the hierarchy (parented, attached, and !GONE), since otherwise
the views would not be laid out, the flags wouldn't be cleared, and requests
are superfluous anyway. However, this logic only checked whether the
requesting views were GONE, whereas the check should include the entire
parent hierarchy of the views (since a view with a GONE parent is still not
visible to the user).
This fix adds that additional check and cleans up other parts of the previous
code, such as not bothering to post() requests that occur during the second
layout pass unless those requests are also valid (coming from visible views).
Issue #8370042 Path seems to be in an infinite layout loop
Change-Id: I7aaf701229adfeee349a9a7c9ec14585735ba9f6
Show notification when a bugreport is finished, letting the user
launch a SEND_MULTIPLE intent to share them. Add dialog that warns
user about contents before sharing. Since bugreports are now stored
in private app data of the Shell app, use FileProvider to build Uris
that we can grant others access to.
Define BUGREPORT_FINISHED as being a protected broadcast. Delete
older bugreports automatically to reclaim disk space. Migrate any
Intent extras to ClipData when building PendingIntents.
Add --receiver-permission support to am shell command.
Bug: 7005318
Change-Id: If6c607dbcf137362d5887eac482ff7391563890f
