...Should Skip Unsecure Lockscreen (ICS)
Also while I am in there, clean up logging of intent objects to include
even less sensitive information, while showing the true Intent in dump
output (since apps can't get to that).
Change-Id: I35fed714645b21e4304ba38a11ebb9c4c963538e
If the app had activities still finishing, when we checked whether it was
now stopped we would get told no. Also some other improvements:
- Schedule an idle as part of the force stop, to get any finishing
activities out of the stack soon rather than waiting for some activity
to idle.
- Don't filter out stopped system apps. This is dangerous because
system apps may have no way for the user to explicitly launch them,
so they could get put into a stopped state for which there is no way
to get them out. Also if the user really wants a system app to not
run, the new disabling mechanism is more appropriate.
Change-Id: I34003f21dac29e2ca0f66a23b88c710de41bab99
Provider was not being removed from the class map because it was using
the wrong key. D'oh.
Also a little cleanup.
Change-Id: I318e8b1a265318ac1474e0a7f14f27f89f357505
When force stopping an app, when removing its activities also finish any
activities from other apps above it in the task. This avoids some situations
where the task gets into a bad state where its root becomes a different app.
Change-Id: I79e5cd520ae321bec80adefd2ccc2b0370ace372
The resolver activity was hiding the following activity from recents.
Also some other fixes: a little better memory use debugging, removed
some unneeded code from window manager, moved some system activities
into their own process, added some more running process information for
manage apps.
Change-Id: I66687d16989ff965d524b92dc360f37c19199717
Persistent process can no longer use hardware acclerated drawing
when running on a low-memory device.
Change-Id: I3110335617af1c98fcede9bf41f4a1d0c20d0e87
Change-Id: Iff2cfec5280a314989d915aa830c16124f921611
5214105: taking a screenshot while "Android is upgrading..." crashes device
5109947: Race condition between retrieving a content provider and updating its oom adj
...(when turning display on after recently turning it off)
Also clean up when we decide to turn the screen on to improve that
transition. There are still problems here with turning it on
before the wallpaper gets dispayed.
Change-Id: I2bc56c12e5ad75a1ce5a0546f43a845bf0823e66
This introduces a new facility for code during the boot process
to display messages to the user through a progress dialog. This
is only for use when performing longer-than-usual post-upgrade
operations such as running dexopt on applications or upgrading
databases.
Change-Id: I0e78439ccec3850fb67872c22f235bf12a158dae
In UsageStatsService, separate last-resume times from the rest of
the statistics, and serialize them to an XML file daily.
This way, ApplicationsProvider will still be able to acces this data,
even thoguh other statistics are flushed to disk and discarded each day.
Bug: 5108745
Change-Id: Id3df3c98243ba02cde16b31e5e29bd9ff3602108
The activity manager now take care of plugging the correct settings
into the OOM killer in the kernel. This is a lot cleaner because
it is really central to how the activity manager works, and nobody
else cares about them.
Taking advantage of this, the activity manager computes what it
thinks are appropriate OOM levels based on the RAM and display
size of the device.
Also a small optization to the package manager to keep a binding
to the package install helper for a bit after done using it, to
avoid thrashing on it.
And some new APIs that are now needed by Settings.
Change-Id: I2b2d379194445d8305bde331c19bde91c8f24751
- Improve how we handle processes that have shown UI, to take care
of more cases where we want to push them into the background LRU
list.
- New trim memory level for when an application that has done UI
is no longer visible to the user.
- Add APIs to get new trim memory callback.
- Add a host of new bind flags to tweak how the system will adjust
the OOM level of the target process.
Change-Id: I23ba354112f411a9f8773a67426b4dff85fa2439
...apk reinstall; affects user privacy
Disconnecting a ServiceConnection after an app is torn down could
impact the bookkeeping of the same service if it has been started
for the app.
Also address issue #5073927: GSF process can't be killed
A new flag allows the systems location manager service to tell
the activity manager to not pull bound services up forever into
the visible adj level.
Change-Id: I2557eca0e4bd48f3b10007c40ec878e769fd96a8
A later CL will introduce an API for querying whether a given package
runs in a persistent process; UIs such as Settings will be able to use
that to determine whether to disable the 'force stop' action.
Change-Id: Iab47c2300fdce285da7d83e02263c9a5f69edd70
Also improve how we handle services, keeping track of whether they showed
UI and if so putting them immediately on the LRU list.
Change-Id: I816834668722fc67071863acdb4a7f427a982a08
To profile the looper, run the following command:
adb shell am profile looper start <process> <file>
adb shell am profile looper stop <process>
Change-Id: I781f156e473d7bdbb6d13aaffeeaae88bc01a69f
This should fix a leak of process death recipients in the activity manager.
Also add debugging of content observers to try to track down what looks
like a leak of them in the content service.
Change-Id: Id6823679493ef0cde5307bb66490ebe31b878556
We now collect more detailed information splitting the maps into
additional useful categories.
Fixed some bugs in account, such as not correctly handling all of
the current dalvik allocations.
The activity manager now prints a final summary of all pss organized
by the apps and the categories.
Change-Id: Iafc5f27c998095812b1483c6803b8e0f0587aeae
Now classify background processes into a set of bins of how much
memory they should try to clear. The last bin also involves
destroying all activities in that process.
Removed the old code for the simulator that is no longer needed
(yay). The debugging features it had are now integrated into the
regular oom adj code.
Small fixes to load average service.
Change-Id: Ic8df401714b188c73b50dbc8f8e6345b58f1f3a0
This patch enables the Zygote to tell the ActivityManager when
it has started a process with a wrapper attached so that the
ActivityManager can allow it extra time to start up or process
events.
This is useful when wrapping an app with Valgrind or other tools
which add significant runtime overhead.
Bug: 4584468
Change-Id: I5db6f2f15cd30b0ec40f547d2fadfa216de2926d
This will let dalvik implement backwards-compatibile behaviors based on
an app's targetSdkVersion.
Bug: 4772166
Change-Id: I935c5ea9144e8b4e6e21089547287486e2234b7f
This turns on the super-verbose but indispensible logging of all native method
calls and all calls to JNI functions (for third-party code only). In particular,
if you have a local reference bug, you can search for the reference given in
the crash and see exactly where it came from. In every case I've seen so far,
that's pinpointed the bug exactly.
Change-Id: Ifb7ba02ae637bdd53cd8500febdcb9d4d7799bda
Location manager now checks for such intents, and logs a warning when
they are given to it. Nothing thrown yet, it needs to check the
targetSdkVersion of the caller somehow.
When sending the pending intent, we require that the recipient hold the
appropriate permission. This should pretty much close the security hole.
Includes a bunch of infrastructure in the activity manager needed to
support all this.
Change-Id: I4dba7a98a7b8bbb9e347666451aa9cb1efad1848
This should help third-party developers debug their apps.
Tested by adding logging to dalvik and launching a debuggable app.
Change-Id: Icec66825709e399e238b4ff00f2bc596485a3a60
When animating away a fragment, we were not putting it through
the last part of its lifecycle (onDestroy() etc).
Also, retained fragments that have a target were broken. Oops.
Change-Id: I5a669b77a2f24b581cde2a0959acf62edb65e326
