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 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
Following boot the initial activity was automatically resumed even if
a lockscreen is obscuring it. Refer to CL 363859 for why this breaks
things.
This fix pauses all activities the first time a lockscreen appears.
Completes the fix for bug 10732489.
Change-Id: I6fcac14b574c495aa0e16d798cddc1263c6b4c25
...ActivityManagerService.updateLruProcessInternalLocked on bluetooth
Don't try to move process records associated with dead service
connections.
Technically we should probably be clearing the binding/service's
app entry so we don't get into this case, but the least intrusive
change for now is this check.
Change-Id: I6683e692eb5a8fa4f8ec1fa31bd63ec3d7f878ef
...activity chooser from being shown
Add more useful output when intent filter debugging is enabled.
Change-Id: I3722b03ed625046398e81233cf7fb6aa5ded5eca
...in ActivityManagerService.updateLruProcessInternalLocked on bluetooth
Add more debug output to help track down what is going on.
Also fix a little problem where, when a service ANRs, if you ask to
wait and it still wasn't responding, the ANR dialog wouldn't be
shown again.
Change-Id: I5be2b1705a0a39ca2992624ae683945c5f38065d
Gah I messed up when refactoring so it would always be told
RAM is low.
Also slightly tune the low memory parameters to go into low
memory states a bit more aggressively.
Change-Id: I5f970349760ad349d515a85c266ab21b387ee353
...be uncached and too large
When the device is in a low RAM state, when we go to pull a cached
process out to use for some background operation, we can now kill
the current process if we consider its size to be too large.
Note that the current implementation for killing processes is to
just use the same killUnneededProcessLocked() method that we already
have for other things like too many cached processes. This is a
little wrong here, though, because in this case we are at the
point where the caller is actually looking for a process to use.
This current code is not actually removing or cleaning up the
process, so we still need to return the now killed ProcessRecord
and let things fall out from there, which typically means the caller
trying to make an IPC on it and failing and falling into its "oh
no the process died unexpectedly" path. All code using this
*should* be able to handle this correctly, anyway, since processes
really can be killed at any time.
At some point we may to make this implementation cleaner, where it
actually tears down the process right in the call and returns a
null ProcessRecord. That is very dangerous however (we'd need to
go through all paths into this to make sure they are going to be
okay with process state changing on them like that), and I'm not
sure it is really worthwhile. This intention is that killing
processes like this is unusual, due to processes being too large,
and anyway as I wrote all of our incoming code paths must already
be able to handle the process being killed at this point and one
could argue this is just another way to excercise those code paths.
Really, the main negative to this is that we will often have spam
in the log with exceptions about processes dying unexpectedly.
If that is the only issue, we could just add some conditions to
quiet that up at in this case.
We don't want to compute the size of the process each time we try
to evaluate it here (it takes 10s or ms to do so), so there is now
a new field associated with the process to give us the last pss
size we computed for it while it was in the cached state.
To be able to have better cached pss data when we now need it, the
timing for computing process pss has been tuned to use a much
shorter delay for the situations when the process has first switch
into a new state. This may result in us having a fair amount more
pss data overall, which is good, as long as it doesn't cause us to
be computing pss excessively and burning cpu.
Procstats now also has new state to keep track of the number of
times each process has been killed by this new system, along with
the min, avg, max pss of all the times it has happened. This has
slightly changed the checkin format to include this additional data
at the end of pkgkills/prockills lines.
Other changes here:
- Fixed a problem where GPU RAM was not being seen when dumping
the full RAM details of a process. This was because in that
case the system would ask the process to compute its own MemInfo,
which it returned, but the process doesn't have permission to
access the files containing the GPU RAM data. So now the system
always computes the MemInfo and hands it to the app.
- Improved broadcast delays to not apply the delay if the next receiver
of the broadcast is going to run in the same process as the last
one. A situation I was seeing was an application that had two
receivers, one of which started a service; we are better off letting
the second receiver run while the service is running.
- Changed the alarm manager's TIME_TICK broadcast to be a foreground
broadcast. This really should have been anyway (it is supposed to
go out even minute, on the minute, very accurately, for UI elements
to update), and is even more important now that we are doing more
things to delay background broadcasts.
- Reworked how we maintain the LRU process list. It is now divided
into the two parts, the top always containing the processes holding
activities. This better matches the semantics we want (always try
to keep those around modulated by the LRU order we interleave with
other cached processes), and we now know whether a process is being
moved on the LRU list because of an activity operation so we can
only change the order of these activity processes when user operations
happen. Further, this just makes that common code path a lot simpler
and gets rid of all the old complexity that doesn't make sense any
more.
Change-Id: I04933ec3931b96db70b2b6ac109c071698e124eb
The idea of multiple processes serving as home was unfeasible.
- Revert "Allow for more than one home app." commit
e428a7f662.
- Assign ActivityManagerService.mHomeProcess to the process of the
root activity of the home task.
Addresses bug 10342471.
Change-Id: Ifb494626107d24de1306e320a18206d5b176a7c0
...while setting up a new user from settings.
We can now delay broadcasts when there are enough background services
currently starting (still set to 1 for svelte devices, 3 for normal
devices).
Add new intent flag to not allow receivers to abort broadcasts, which
I use to fix an issue with the initial BOOT_COMPLETED broadcast not
actually requesting pss data at the right time -- it can now be sent
as an ordered broadcast without the ability for the receivers to cancel
it.
Change-Id: I51155bbbabe23e187003f3e2abd7b754e55d3c95
NPE at com.android.server.am.ProcessRecord.resetPackageList(ProcessRecord.java:596)
Take care of some more cases now that baseProcessTracker can be null.
Change-Id: I394c0b7802788118c3ad6bcac5dfdd23eeda8d58
We now have the activity manager kill long-running processes
during idle maintanence.
This involved adding some more information to the activity manager
about the current memory state, so that it could know if it really
should bother killing anything. While doing this, I also improved
how we determine when memory is getting low by better ignoring cases
where processes are going away for other reasons (such as now idle
maintenance). We now won't raise our memory state if either a process
is going away because we wanted it gone for another reason or the
total number of processes is not decreasing.
The idle maintanence killing also uses new per-process information
about whether the process has ever gone into the cached state since
the last idle maintenance, and the initial pss and current pss size
over its run time.
Change-Id: Iceaa7ffb2ad2015c33a64133a72a272b56dbad53
This significantly reworks the logging we do when
all cached processes are killed:
- We now collect the list of processes in-place so we
have a snapshot of exactly when the low memory situation
happened.
- In that snapshot we include the key process state: oom
adj, proc state, adj reasons.
- The report then asynchronously collects pss information
for those processes.
- The ultimate data printed to the log looks like a mix
between the "dumpsys meminfo" and "dumpsys activity"
output. This code no longer uses "dumpsys meminfo"
itself, so some of that data is no longer included,
in particular pss organized by allocation type.
In doing this, I realized that the existing code that is
supposed to run "procstats" is not currently working. And
at that point I realized, really, when we are collecting
this pss data we'd really like to include all those native
processes using ghod-only-knows how much RAM. And guess
what, we have a list of processes available in
ProcessCpuTracker.
So we now also collect and print information for native
processes, and we also do this for "dumpsys meminfo" which
really seems like a good thing when we are printing summaries
of all pss and such.
I also improved the code for reading /proc/meminfo to be
able to load all the interesting fields from there, and
am now printing that as well.
Change-Id: I9e7d13e9c07a8249c7a7e12e5433973b2c0fdc11
Before:
4539 does not have permission:android.permission.CLEAR_APP_USER_DATA to clear datafor process:com.android.chrome
After:
PID 4539 does not have permission android.permission.CLEAR_APP_USER_DATA to clear data of package com.android.chrome
Change-Id: Ic466decb050e4fa7f3fee4098c4f2abdc6cedf5c
Reverts extension to assist context API to query
foreground services for assist context data.
Also hides Intent.ACTION_VOICE_ASSIST because
nobody's actually using it yet.
Bug: 10461702
Change-Id: Idf6836adc659b434e11ebb2b98e8b814c94a7227
Make it a little easier to diagnose input dispatch timeouts by
providing the detailed reason as the ANR annotation in the log.
Bug: 10689184
Change-Id: Ie18fd9ad066b0673d1f57c030e027ad0085f4650
We now keep track of which process and service states are actively
in use, and remove any that are not in use during a commit. The
activity manager needed to be tweaked to report this data, and ensure
it does not try to operate on one of these structures when not in
use.
Also some other fixes:
- We now keep track of process names associated with services, for
display in the UI.
- Keep track of total run time for each service, also for UI.
- The parceled format is more efficient, not storing duplicates of
process/package names, and writing times as ints when possible.
- Reduced commit period from 1 day to 12 hours, so that our UI can
be a little closer at its attempt to display the stats over 1 day.
Change-Id: Ifeda0ffe963a7b49d8eb2a3f6923f3a5e71a4e43
http://ag/323631 added the provideAssistData
attribute to the Service manifest tag.
It did not, however, add that attribute to
public.xml - making it impossible to actually
build a service that defines said tag.
So, add it.
Now that the attribute is where it should be,
restore @link notation to ServiceInfo.java
without breaking the offline docs build
( see http://ag//340279 ).
Also, make some log warnings related to
providing assist data slightly more verbose.
Bug: 10573008
Change-Id: Ie2bcb411c182d69738a2fa4a74de3171b9b9c455
- There is an assumption that moving a task to the back moves it
behind the home activity. This fix ensures that the home activity
will be launched by some activity before the task that has been
moved to the back.
- Convert "private final" declarations to private only.
- Convert container tests for size()==0 to isEmpty().
- Remove unused variable.
Fixes bug 10228536.
Change-Id: I51741ee7a09652e27afffcc50c14953bf0aa27ea
Since ContentProvider file operations can end up doing substantial
network I/O before returning the file, allow clients to cancel their
file requests with CancellationSignal.
Ideally this would only be needed for openFile(), but ContentResolver
heavily relies on openAssetFile() and openTypedAssetFile() for common
cases.
Also improve documentation to mention reliable ParcelFileDescriptors
and encourage developers to move away from "rw" combination modes,
since they restrict provider flexibility. Mention more about places
where pipes or socket pairs could be returned.
Improve DocumentsContract documentation.
Bug: 10329944
Change-Id: I49b2825ea433eb051624c4da3b77612fe3ffc99c
When Activity.convert{To|From}Translucent() is called the
ViewRootImpl is now notified when it is safe to convert the Canvas
from translucent to opaque and back to translucent. This will make
it possible to save resources when compositing opaque layers.
Fixes bug 10349536.
Change-Id: I7282aee1d54601fb00611d20be204bf164d873f6
Having a single mHomeProcess in ActivityManagerService ignores the
possibility of multiple processes serving as home. Particularly when
we have a home activity that only serves to launch the true home
activity.
Fixes bug b10296766
Change-Id: I9e5c9c955c64f4b3df856b6bc66d6a0d93f85aab
Now that granted Uri permissions can be persisted across reboots,
offer APIs to discover them. Returns incoming or outgoing grants
matching the requested flags and mask. Add helper method to discover
"open" documents using this new API and filtering for non-documents.
Require that callers own at least of the filtering packages to avoid
exposing all grants. Switch internal grant tracking to use ArrayMap.
Change-Id: I0a755f221d0d160b411f8d3cfc48279b64345733
