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
Some events in the future may not have originated
from a class, so we shouldn't be using ComponentName.
Bug:17259858
Change-Id: Id7fe3245b91596cf27ae4ec51655602f01665622
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
1. An external contribution changed the ordering of views for
accessibility. While it attempted to fix a platform issue
for a comparator breaking transitivity, it changed the way
we order views and results in very unnatural accessibility
traversal order. It also broke CTS tets. This change tweaks
the comparator which fixes the tests and improves traversal
order.
2. If there is at least one accessibility service which cares
about windows we register a callback in the window manager
for window change notifications. We are updating the window
list on this callback. There was a case where if the service
requests window updates and immediately asks for the windows
it gets none as we have not received a callback from the
window manager yet. Now this call returns after we get the
callback in a timed fashion. This is consistent with how the
other introspection APIs work.
3. Window info objects are cached in the accessibility service
process. When putting them in the cache a cloning call was
missing resulting in some cases of clobbering windows given
to the client. For example, we get some windows, cache them,
and return these windows to the client. Now a call to clear
the cache arrives while the user processes the windows and
the client windows get clobbered.
4. Added API for checking if a window has accessiblity focus
to be consistent to the API we have to check whether this
window has input focus.
5. Removed some obsolete code.
bug:16402352
Change-Id: Ided6da4a82cc0fc703008c58a2dff0119a3ff317
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
Fixed two minor issues with the screencapture as well.
Updated documentation and added enforceCrossUserPermission.
Bug:16948504
Change-Id: I9a645dcf480a4a044879ba481bce964d06fe5153
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
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
