Dumb typo was clearing the wrong service array, causing
us to sometimes forget we were launching a service.
Change-Id: Ie1aba0e07d19e85a104a5985e3cead5f28a0556a
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
Because recents sits on the same stack as launcher it can sometimes be
above launcher. When we were launching home activity because the flag
told us to we would sometimes launch recents instead. This fix makes
sure that the home activity is on the top when it is supposed to be
launched next.
Previously this was fixed by having recents move itself to the back
of the stack after it launched an activity (b/9750207 and ag/336019).
But that solution caused the AppTransition to be set to
TRANSIT_TASK_TO_BACK which left the SOFT_INPUT_IS_FORWARD_NAVIGATION
flag unset. This in turn caused IMEs to remain unlaunched when
returning from recents (b/10240567).
Fixes bug 10240567.
Change-Id: I35c6619af0e68d0e6d9ab87cad06ea7c27e11e27
Added some code to the activity manager to keep track of
services that are launching and limit the number that can
be launched concurrently. This only comes into play under
specific circumstances: when the service launch is a background
request (so timing is not important) and its process is not
already running at a high priority.
In this case, we have a list of services that are currently
launching and when that gets too big we start delaying the
launch of future services until currently launching ones are
finished.
There are some important tuning parameters for this: how many
background services we allow to launch concurrently (currently
1 on low-ram devices, 3 on other devices), and how long we
wait for a background service to run before consider it to be
a more long-running service and go on to the next pending
launch (currently set to 15 seconds).
Also while in here, did some cleanup of the service code:
- A little refactoring to make per-user data cleaner.
- Switch to ArrayMap.
Change-Id: I09f372eb5e0f81a8de7c64f8320af41e84b90aa3
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
In cases where the client is waiting for an activity to launch
(startActivityMayWait()) it is a bad idea to clear
ActivityRecord.displayStartTime when going into the pause state. If
displayStartTime is cleared before the activity is displayed,
the client will never be released.
This fix keeps pause from clearing displayStartTime if any client
is waiting for the activity to be displayed.
Fixes bug 10095558. But not a permanent fix, startActivityMayWait()
should not be called by any production code.
Change-Id: I7cbdcb04256f4a26233867c52aedd3bc4151adc3
Changes for translucent activity were causing activities to be
launched twice due to a recursive call into resumeTopActivity.
Putting the translucent action onto a handler removes the recursivity
and fixes the multiple launch problem.
Fixes bug 10556969.
Change-Id: I2bb53cd555b0aaf093ab35db2859acb10b58211e
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 was a bug in counting the number of starting services
in a process that would cause it to count too many (it would
increment at any state change while the service is started, not
just when starting/stopping).
Also reduce dumpsys output -- only print summaries for old
data. There is probably no utility in printing the long details
of all that data.
Change-Id: I1c1e901b0214c01eb7d071f23166fc6f3702ca67
- 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
When relaunching an activity re-evaluate the flag that determines
whether to return to the next activity on the stack or to the home
activity upon return.
Fixes bug 10545580.
Change-Id: I5868ce1b494afffcc5afc22abe3b65aa339827bb
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
The warning about an ActivityRecord not being assigned a task was
incorrect in the location modified by this fix. In this case an
existing ActivityRecord is relaunched so it is not necessary to
assign the task to the passed ActivityRecord.
Addresses the warning associated with bug 10181389.
Change-Id: I76d5066c320bf9da2663bc34bcaca801ad4953bc
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
The new wallpaper positioning associated with multiple activity stacks
put animation backgrounds in front of the wallpaper. This caused
hideous jank. Testing for visible wallpaper and moving the background
behind it fixes the jank.
Fixes bug 10078282.
Possibly fixes bug 10247094.
Change-Id: I3f4e07accd7276d59725192081904b791f77781f
For process state, if a top process is making use of another
process, we should probably count the second process as top
as well (instead of IMPORTANT_FOREGROUND). Specially, when
chrome binds to render processes we want those render
processes to be TOP. Otherwise, they end up in the
important foreground state and it looks like they are running
for some other reason in the background.
Change-Id: Id115dbb65dc2b403ffa4bbe4e7837564eb3b9cb5
Also fix a bug where, when parceling the stats, we were
computing the final duration values too late. We need to
do that before we write the long table.
Change-Id: Idb6c1ed95417448c56973fe5866bfb3570e525f4
Make sure screen layout changes are taken into account in Configuration diffs.
Initialize the SystemProperty from Global settings on startup of
ActivityManagerService.
TextUtils checks the override flag to decide if the default layout direction
should be forced to RTL.
Bug: 10244047
Change-Id: I23a2583d790a355060d0d898ba44e5f7dc896b46
PAC (Proxy auto-config) files contain a single javascript function,
FindProxyForURL(url, host). It gets called to determine what proxy should be
used for a specific request.
This adds PAC support to the system. The ProxyProperties has been modified
to hold the PAC file when one is present. The Proxy method
setHttpProxySystemProperty has been modified to insert a PacProxySelector
as the default ProxySelector when it is required. This new ProxySelector
makes calls to the ConnectivityService to parse the PAC file.
The ConnectivityService and the WifiConfigStore have been modified to support
saving the extra PAC file data.
The ConnectivityService now has a class attached (PacProxyNative) that
interfaces to the native calls for PAC files. The parsing of the PAC file
is handled by libpac (which is being added to external/) which utilizes
libv8 to parse the javascript.
As a fallback to applications that don't use the java ProxySelector, the proxy
is setup to point to a local proxy server that will handle the pac parsing.
bug:10182711
Change-Id: I5eb8df893c632fd3e1b732385cb7720ad646f401
