Bug: 10916655
Add a stash where the SyncHandler can copy and place
msgs rather than run them. After boot is complete
we iterate through the stash in order and send the
messages off.
Change-Id: I9c175ee79fe60952346003a29225b8687979b44e
Fixes jank exposed in 10881705. Specifically background activity
animating up along with translucent activity. Repro steps on manta:
1. From home start Settings.
2. Press home.
3. From home start Downloads (translucent activity that takes 85% of
screen).
4. Observe that as Downloads zooms up the 15% boundary that should be
dimly transparent are showing Settings.
The cause was that there is a finishing activity in the Downloads task
that was used to launch the DownloadsActivity. The existence of that
activity kept the logic from recognizing that the home activity was
behind the DownloadsActivity, not the Settings activity.
This fix descends through all of the activities in a task sitting on
home and makes sure that they only keep home from showing if such
activities are not finishing and visible.
Change-Id: I607afce6b0000b4db634f2ce40a6c37fcee369d7
Not dealing with the case where there is a null list.
Also fixed some bugs I found while looking at this:
- When resetting the stats, we would use a newly computed time stamp
for the total durations rather than the one we used to reset the
proc/service entries. This would result in them being able to be
slightly > 100%.
- There was a bug in how we split a single process state into its
per-package representation, where we would but the cloned process
state into the new package's entry (instead of properly for its
own package entry), to be immediately overwritten by the new
process state we make for that package. This could result in
bad data for processes that have multiple packages.
- There was a bug in resetting service stats, where we wouldn't
update the overall run timestamp, allowing that time to sometimes
be > 100%.
- There was a bug in computing pss data for processes with multiple
packages, where the pss data was not distributed across all of the
activity per-package process states.
- There was a bug in computing the zram information that would cause
it to compute the wrong value, and then never be displayed.
Finally a little code refactoring so that ProcessState and ServiceState
can now share a common implementation for the table of duration values.
Change-Id: I5e0f4e9107829b81f395dad9419c33257b4f8902
Various authenticator results such as getAuthToken and addAccount might
result in an Intent returned to the AccountManager caller. A malicious
authenticator could exploit the fact that the Settings are a system app,
lead the user to launch add account for their account type and thus get
Settings to use the intent to start some arbitrary third parties Activity.
The fix is to make sure that the UID of the app associated with Activity
to be launched by the supplied intent and the Authenticators UID share
the same signature. This means that an authenticator implementer can only
exploit apps they control.
Bug: 7699048
Change-Id: I34330454c341e6a8422ca1ed3b390466a0feedce
Make sure that moveStackWindowsLocked() is called every time that the
stack ordering changes. This will rebuild the window list. Previously
the call was being made after the moveStack() call which got forgotten
in the addAppToken() causing the home stack to obscure incoming phone
and video calls.
Fixes bug 10023223.
Fixes bug 10678010.
Maybe fixes bug 10858941.
Change-Id: I59922dc979a19210008eac1f528704984c63c886
Do not use the shortcut of the package name to identify the home
activity.
Fixes bug 10963726.
Fixes bug 10920950.
Change-Id: I725781a26672b055a816994aee6ea458a7f07c88
Killing the GEL search results was killing everything in its package.
This fix keeps the home process from being killed when a task in its
package is killed.
Fixes bug 10927223.
Change-Id: I56e75f0a0118885a1604cbd70320bbdb4f8cf1a2
When loading historical records for previously used printers we
now ignore the ones whose target print service is not installed.
bug:10955652
Change-Id: Ib295e7d88ed3c308ef6d8a11bdc1792ebbb6d526
1. We want the files for a print job to be removed as early as possible
typically because the print job was cancelled, completed, the app
or the spooler crashed during print job construction. We were keeping
around in the spooler and hence to disc infos for jobs that are in
final state since the app that created them may hold a reference to
a local print job objec whose info it can access to get the latest
print job state potentially after the job reached final state. The
issue was that we were persisting to disc created print jobs which
were during construction which requires careful handling for the
various cases above. This is tricky and error prone.
We used to tell the spooler to forget the print jobs infos when the
app that created them died. The implementation to forget a print
job was not careful and was nuking currently running print jobs in
addition to the ones in a terminal state. Further, if the app dies
before a print job is completed we were left with a stale print
job in the spooler since we missed the signal to forget it (assuming
we forget only inactive jobs). These issues suggest that the approach
is problematic.
Now we have a cache of print job infos for the jobs an app created.
This cache is updated when the state of a print jobs changes using
the new print job state observation code. When the app dies we
remove the cached jobs for that app. Now if the app calls to get
the print jobs it gets the cached ones, i.e. the print jobs it
created during its lifetime, plus the print jobs that are still
active fetched from the spooler. Note that transient state cannot
be kept in the spooler since we unbind from it if there is no
work and it may get killed.
2. Improved the print sub-system logging code to show the cached
print job infos for apps and also dump the print job PDF file
names.
bug:10958357
Change-Id: I6f7c1968b6b7ba5be182a10df044ff7ea1fc3a61
The home activity was being returned to when any activity in a task
that was launched from home crashed. If there were still activities
left in the task then the crash should have brought up those
activities next, not home.
This may be a partial fix for crashes where the back stack was showing
up under launcher icons. Bug 10858941.
Change-Id: I840a25bd8395bfce46f4e21b112d78b12884706d
Since binder call permissions are not transitive by design,
the proper way to fix this is to have the call talk directly
to keyguard from the navigation bar.
Fixes bug 9409008
Change-Id: Ibd90a79bb638c969b514455a2ad93c6ff668222d
If an activity is visible behind the keyguard when it is launched
by another activity then there would be no call to dismissKeyguard.
Because the other activity is pausing the call to dismissKeyguard
is skipped in startActivityLocked(). And because it is already
visible the call to ActivityRecord.windowsVisible() is never made and
the call to reportActivityVisibleLocked() which calls
dismissKeyguard() is also never made.
This change recognizes when an activity is resumed and visible and
calls dismissKeyguard() in that case.
Fixes bug 10732489.
Change-Id: I3de1350a55231aaa14dadc8709fd0fcf4960742c
The PacManager now waits until the local proxy is bound and the PAC file
is downloaded before sending out the proxy broadcast.
Bug: 10895515
Change-Id: Iaa7fc0989b52453aeeb720b44df0fca0fcb959ca
Back out changes from CLs ag/363992 and ag/363859. These introduced
the bugs found in bug 10917435 which is now fixed. Note that backing
out these changes reintroduces bug 10732489.
Change-Id: Ic5105dd4cfc8bf79c6f06188283d1ee3680c370c
This fixes a bug in parsing the package name from a file name. The suffix
was not taken into account, resulting in all restrictions files being
removed on switching to a user.
Bug: 10947554
Change-Id: I62725bbbdc0e15609872de3896130d4acbc35386
Check and throw if callers request invalid grant flags. Add API to
test if a Uri is backend by a DocumentsProvider.
Bug: 10919391, 10935608
Change-Id: Ifa6afefb95983558c8c64dc15ddf650e9fe07080
PackageManager#queryIntentServices javadoc contract states that this
method (and the like) never returns null, rather an empty list if
no result is found. However, there is a path in the PackageManagerService
that returns null, thus breaking the contract. Handling the null list
explicitly.
bug:10930560
Change-Id: I708c51b8b7075e529145c8b0bf159efd6b697532
Now when memory low, if a service's process is above
a selected pss, then the process is not allowed to go
in to the service a list.
Also simplified the normal meminfo details dump to not
include the shared dirty and shared clean sizes by
default, since these can be very confusing. You will
still get to see them with the "-a" flag.
Finally some small steps to better managing service
processes in the LRU list, so hopefully we can some
day be better about letting them drop down in the list
when there isn't really much interesting happening in
the process. Not yet used at this point.
Change-Id: I654bfd6d05de2a63120185ebb15ffda8cbeb5dac
Change our Intent flag to indicate that a Uri permission grant is
persistable, but don't actually persist it until explicitly taken by
the receiving app. This prevents apps from spamming each other if
persisted permissions aren't really required.
Remember the last time a persisted grant was taken by an app, and
use this to prune away the oldest grants when the number of grants
grows too large. Allow apps to query persisted grants they are
holding, and allow them to release previously persisted grants. Add
public UriPermission class to return grant details and timestamp.
Track various permission strengths separately, and combine together
after each mutation pass. Persistable grants are currently treated
like global grants, but they could be moved to have owners in the
future. Require that grant holders trying to extend a persistable
permission actually hold a persistable permission themselves.
Bug: 10835779
Change-Id: I95b2f797c04ce7fd2612f9a644685dbd44e03759
The previous fix for keeping activities from running on startup,
ag/363992, was keeping the home task from launching when the
keyguard should have allowed it.
This fix permits the home activity to launch in such situations.
Fixes bug 10916877.
Change-Id: I429f0d5a13e06a247b9b6b7241f9a3514044c371
The problem was that the ResolverActivity filters some activities
out of the list it shows, but it uses that display list as the
list of components the preference is set against when ultimately
setting it on the package manager... but that filtered list is *not*
the right component set, since it is not the same as the package
manager's view on it.
The fix here is to retain the original set of matching components
and use that when setting the preferred activity. Note that this
does mean that in very unusual cases where filtering is happeing
(such as one of the activities not being exported but being seen
as a possible completion from another app), then you will be setting
the preference for the complete set. Ultimately we probably need
to have the package manager apply these filtering rules up-front so
this is all consistent, but this is a very rare case so not that
important.
And then most of the change here is just improving the debug
output for intent resolution.
Change-Id: Ie35ac2c05a45946439951bbf41433c8b7de79c05
