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
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
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
https://googleplex-android-review.googlesource.com/#/c/527772/
correctly stopped adding listen requests to the mNetworkForRequestId
sparse array, but when we remove requests, if it's not getting
serviced by a network, we don't remove it from the network. That
means that when we go to send a notification for that network we have
a request affiliated with the network, but don't have data for the
request and hit this NPE.
If it's not a request, don't do the optimization and remove it only
from the network servicing the request, but instead scan all networks
and remove it from each, if found.
bug:17239054
Change-Id: I49165ed08c224ef20f703469f9ce39df5f21b163
Use MediaProjectionManager to determine whether or not
screencasting is active, when it changes, and to stop
casting.
Also:
- Implement hashCode/equals on MediaProjectionInfo
- Fix unintentional recursion in the service.
Bug:16488053
Change-Id: Icd1a88f23bbdf1d4c1915b30cb2508f8fe9d6d7e
We are checking whether an app can access an app widget
based on the calling uid and the package name. The package
is mostly to make sure that hosts in different apps do
not accidentally interfere whereas the security is enforced
by the uid.
When remote views adapter binds and unbinds to a remote
views serivce it was passing the package of the context we
create to load resources for the widget instead the package
of the host. Now it is passing the host package and also
we are checking if the caller of bind remove serivce API
is in uid that has the host package - this makes it
consistent with elsewhere.
bug:17226052
Change-Id: I2b0b6669e3dc027037b7481c2871cedabd642433
Was originally removed in ag/522961, but restoring to keep legacy VPN
behavior the same from within VpnSettings. This dialog is only
accesible from VpnSettings and so should only ever be shown for legacy
VPNs.
Bug: 17164793
Change-Id: I06c4e136e1023b8f84edfd15a15264d2e41d325b
Sessions can now zero-copy data directly into pre-allocated ASEC
containers. Then at commit time, we compute the total size of the
final app, including any inherited APKs and unpacked libraries, and
resize the container in one step.
This supports both brand new ASEC installs and inheriting from
existing ASEC installs. To keep things simple, it currently requires
copying any inherited ASEC contents, but this could be optimized in
the future.
Expose new vold resize command, and allow read-write mounting of ASEC
containers. Move native library extraction into the installer flow,
since it needs to happen before ASEC is sealed. Move multiArch flag
into NativeLibraryHelper, instead of making everyone pass it
around. Migrate size calculation to shared location.
Separate "other" package name in public API, provide a path to a
storage device when relevant, and add more docs.
Bug: 16514385
Change-Id: I06c6ce588d312ee7e64cce02733895d640b88456
They'll be rebound automatically at boot, but need to be brought
up immediately. As always they can only be provided by privileged
apps.
Bug 16542048
Change-Id: I9f121a5c111a772deb3f0c44166002a2cbb16ad5
switchUser() now first shows a dialog and the dialog calls
startUserInForeground to do the actual switch.
Bug: 16661752
Change-Id: Ie4e2e9eec8bf7c2116694072ea8555b8254a0e13
