The max limit is now 100 (or 50 on svelte devices), and that is
what everyone used.
Re-arranged things so we have a big expensive "fix the world!"
function for recents that we go in to at only select points:
when first initializing the system, when external storage comes
and goes, and if we detect something wrong with the recents
structure.
With that, now getRecentTasks() and addRecentTaskLocked() are
generally much simpler, doing very little work in most cases.
This will help a lot with scaling up to many more recents
entries.
Change-Id: I7b5ae89edc06568f68c8af54a4420aff7635581c
We keep per user settings for enabled print services which are
observed to update the print manager service state. We were listening
to all user changes but the handling code was not updating the state
of the user whose settings changed, rather the current user.
Added hidden APIs in content observer to know which user changed
and now the print manager serivce handles content changes for the
correct user.
bug:16977006
Change-Id: I71ec88c8f3f38cb405844c13ab83695c2029eb79
Pending createSession request for the package removed led to the tune request
with invalid channel URI. This change prevents crash from invalid URI by cleaning
up the pending requests on the package removal.
Bug: 17214114
Change-Id: I26fdf9eb45a5fec9032926a1c2994831c07b4fbe
IME was being hidden by keyguard even if the window it was attached
to was showing. This change shows the IME if the window it is
attached to is hiding the keyguard.
Also fix an NPE that was crashing systemui.
Fixes bug 16457525.
Change-Id: If587eefa7b1e0ae26713906a76c0766ebaae69a6
Switch second phase of notification sorting to lexicographic
string comparison in order to enforce a consistent comparison.
Note that this slightly changes the logic: Within groups we
previously fell back on authoritative rank comparison when
one of the notificiations didn't have a sort key. Now we
just replace missing sort keys with " ".
Bug: 16626175
Change-Id: I91f4f4afeeb2c8edda6cd2668011a7367795086c
In application processes, monitor for when we start getting close
to the Dalvik heap limit, and ask the activity manager to try to
prune old activity instances in that case.
Add an explicit API for apps to ask that they have their own
activity instances cleaned up, if they want.
Fix some bugs in launching activities that were not correctly
applying the "multi task" behavior in the appropriate situations
of document-centric recents.
Clean up the activity manager's process removal code to all share
a common path.
Add a new "Spam" option to ActivityTests, which continually creates
new tasks, checking that the activity manager will now prune old
tasks rather than letting the app run out of RAM.
And while I was was doing this, I found problems with the path
for bringing an empty task to the foreground -- it could make
a new task instead of re-starting the root activity in the
existing task. This is fixed, and some code in the recents
UI for working around the bug is removed.
And as long as I am doing that, we now have nice hooks in to
the activity manager for AppTask to give some APIs for better
managing the task, so add those along with more tests for these
APIs in ActivityTests.
We should look at also having the activity manager try to prune
old tasks when it sees app processes being killed, to better balance
memory use across multiple processes when some processes may host
many documents. That however is for another CL...
Change-Id: I2bb81c3f92819350c868c7a7470b35817eb9bea9
Moving apps to/from SD cards has historically been neglected, meaning
it can easily break. This happened most recently for split APKs,
64-bit native code, and multiArch support.
To make this easier to maintain, treat move as a no-op upgrade,
following the inheriting code path that split APKs depends on.
Also clean up scary places where different flavors of flags were
being combined, and remove unused flags. Fix media broadcasts to be
sent based on existing app storage location.
New API to abandon install session without opening it.
Bug: 17158495
Change-Id: Ia33bf8f6fdaae099124dfe534f0e320b37bc8e16
Delay the launch of Home until after the USER_INITIALIZE broadcasts
are delivered, to make sure that any disabled HOME activities are
enabled.
Bug: 15709297
Change-Id: I796a40131f82989782cf5699bcc2e1da2cafbc6b
When the NetworkMonitor is told a network disconnected and a sign-in
notification has been shown to the user, the NetworkMonitor requests
the notification be removed. This request goes to the
ConnectivityService who may have already removed the NetworkAgentInfo
from mNetworkForNetId so we cannot look up the NetID in there.
There is no harm in allowing notification hiding for networks that
are disconnected as the notification logic does not effect the
Network state (like the validation message that caused the addition
of the Network liveness check).
bug:17261757
Change-Id: Id0a299e230ae37e641ac2faeebc45550e27c1fa4
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
