When relaunching activities the window manager clears out all windows
by calling a ViewRootImpl.die() in a deferred fashion. Then it
immediately deletes the ViewRootImpl and its view from its list
of windows. When the die() is eventually executed it calls
dispatchDetachedFromWindow() which tries to remove the previously
removed windows causing an Exception to be thrown.
This change waits to remove the windows until after die() has been
completed. Fixes bug 8253030.
Change-Id: I5b41be1c6b776e32128c064267653db98bd95292
Added new field (+setter and getter) to SynthesisRequest with
Uid of a calling process. TTS service will be able to discover
packages names associated with caller using
PackageManager.getPackagesForUid.
This will allow to block buggy or poorly designed programs from
an unintentional DDoS attacks against TTS service.
Bug: 8625440
Change-Id: I5ac0ea191f952495c00301f17efdf28205353ae4
The logic that canceled underlying animations caused a problem
when there were more than one animation in the list (due to removing
items from a list that was currently being processed elsewhere).
Change-Id: Ie207f340b5d7de4ffcf56a26c05ec394abb80224
The new ArrayMap class is more efficient for small collections.
Transitions use maps all over the place to collect/use property
values in setting up the transition animations. Changing to ArrayMap
should be more efficient, especially in terms of memory allocations
and GCs.
Issue #9276256 Transitions: Reduce memory allocations
Change-Id: I07b7d4ba68d5a207808eca11943aa3578fa90e3e
Previously, ValueAnimator would always call into the Trace class to
log start/end events. When the animator is an ObjectAnimator, this
call necessitated building a new String to capture the animated property
name. This fix puts the calls to Trace inside a check for isTagEnabled(),
to ensure that we only bother building the trace name when tracing is
actually enabled.
Change-Id: I56ef093f3b67b31a19c861f9d1e44a84341edf53
The behavior of running a transition is janky and unpredictable,
when there is already a transition running on the same scene root.
Usually, the new transition simply jumps to the end values, or
jumps to the start values for that transition and animates from
there.
A better approach is to cancel any running transition first, the
start the new transition from that point.
Even better would be to blend old/new transitions, or at least adjust
the animation timing according to where/when the previous transition
stopped. In the meantime, this fix is at least better than the
previous approach of ignoring running transitions.
Change-Id: I4f5fabb55f6454f1e9d66589a9a7c36f9fc013fb
Moves the call to onScrollChanged from onTouchEvent into onOverScrolled,
which ensures only one of scrollTo or onScrollChanged will be called in
a single execution.
Bug: 7584549
Change-Id: Ibccd98a30835efad75eb41bcdd4b136e1b8e0ddd
Treats headers and footers as "enabled" list items when header and footer
dividers are turned on. Also fixes incorrect drawing of dividers when
"stack from bottom" is enabled.
Bug: 7288159
Change-Id: Ibfc48841502a410357db04aaed01072703c7d36c
setDuration() wasn't handled correctly for TransitionGroup; it should
propagate the value to its children.
Also, videos with no ids were not being handled correctly. The transition code was
using the default id on those views (-1) to store start/end data about the view,
causing multiple non-id views to clobber values in the hashmaps. The correct approach
should be to ignore default id values - only store information about the view
instances, not about the unset ids.
Also, added a new test InterruptTest to be used to fix the current behavior of
not handling situations where new transitions start while old ones are still taking place.
Change-Id: I4e880bdbb33cc26d487bceb0d56e463e72f7621f
This change also fixes a race condition. If multiple UI threads are used
in a single process, RelativeLayouts could end up using the same nodes
in different windows, causing mayhem and headaches.
Change-Id: I9ba4a0bf05d44e1a1e7a82443d40c500c657cd7a
