BUG: 16219182
We have seen cases where run-away syncs keep going for a very long time.
The default behaviour is that a sync can run for as long as it wants once
there is nothing else waiting.
This CL will change that, and impose a maximum time-limit of 30mins on
each sync, after when the op with be cancelled and the adapter will go
into back-off.
This behaviour will only take effect for syncs that are not initializations,
or user-initiated.
Change-Id: I1731270ca2a6500b19fc125186aa0b0cd81d1126
- Reverting changes to the existing thumbnail transition to prevent breaking applications
that currently depend on that transition. As a result, we need to create a new, hidden,
aspect-scaled thumbnail transition, and instead use that thumbnail to animate the
recents header so that we don't have to wait to do that inside the Recents activity.
In order for this to work, we also have to ensure that the thumbnail surface destruction
is synchronized with the application that is currently closing (when going down to
recents) or opening (when coming back up). The current thumbnail is destroyed when the
animation ends, but that can be at least 1 frame before the surface for the animating
window is destroyed. We change this by deferring destruction of this thumbnail window
to the animation that is being closed.
Especially on the way up, not having to wait for us to hide the header before doing the
transition up can save us the duration of that first animation (> 100ms).
- Other optimizations:
* No longer creating a new stack view on each transition to calculate the target rect
* Removing unnecessary call to get the thumbnail when transitioning up/down (the actual
window does its own animation.
* We reduced numerous system calls per task by adding a flag to ignore home-stack tasks
and caching the activity label and icon (and task description icon). These caches
follow the same eviction schemes as the thumbnail and icon cache.
- Also tweaked the touch slop for the nav bar swiping gesture to prevent conflicting with
tapping on home (Bug 17109581)
Change-Id: Ica697aad788051a9203edd9351c583e1cb038a71
Save and restore the menu state for Toolbars. This will make sure that
we remember expanded action views and opened overflow menus across
state save/restore.
Remove an extra event post involved in the initial population of
action bar menus. Apparently at some point an extra level of this was
added that isn't necessary. Process any pending menu invalidations
immediately when we perform window state restoration. This makes sure
individual bits of state in action views, etc. are also restored
properly.
Bug 12005461
Change-Id: Icf905698576b11a59641bc319adc62300857906f
BUG: 16219182
The issue is that some adapters get into a bad state where
SyncManager assumes them complete yet they are still going. This
result in ALREADY_IN_PROGRESS coming back from the adapter, the
default retry-time for which is about 10s.
Subject ALREADY_IN_PROGRESS to exponential back-off to avoid waking
up SM every ~10 seconds
Change-Id: I6cef787366436c678bac762ec6daf6212f04badc
This is meant to be used with scaleable vector
drawables, and are chosen as the best match unless
there is a configuration that matches the density
requested exactly.
Bug:17007265
Change-Id: Ic3288d0236fe0bff20bb1599aba2582c25b0db32
If there are activities in persisted tasks then calling addAppToken()
will automatically call addTask(). If there are no activities then
calling addTask() is a nop. In either case the call to addTask() is
unnecessary. It was actually worse than unnecessary because in the
former case we ended up with two identical tasks in the Window
Manager.
Fixes bug 16958544.
Change-Id: I2dc4b50aa94668873c1a783c47e0c696d62616f0
