Setting it when a new activity is being resumed is too soon, because
things like an activity launching an exiting (without being seen by
the user) can knock out the real previous app that we want.
So now we set it when an activity is stopped. At this point it is
going to move from the preceptible to background oom adj, so it is
a good point to determine whether it should be a previous app to
instead put it to that oom adj. This also avoids things like
activities that start and immediately finish from impacting the
previous app.
Further, we keep track of the time each activity was last shown, and
use this to further filter what is set as the previous app.
Change-Id: I72d1cac4de0cc2d4598170296028f11b06918d4f
We could sometimes allow a process to be killed while still waiting for
an activity in it to finish stopping.
Change-Id: Ibf89665c4ad6da6be22de04a82b19ef778a7fda0
We now generate a stack-trace looking thing at the top of the report.
Also fix a bug I hit where the phone window manager was sending a
broadcast before the boot had completed.
Change-Id: I0cee16180e4d05c9bd3fe715212a28f504ec91ac
...through setup wizard after wipe data
Deal with finish() being called when there are no running activities
on the stack.
Also some improved debugging output.
Change-Id: Ia1d3f3f7e7b79c06ca95c738081322fc80282e0d
The msg is now constructed to try to bin these reports in
interesting ways. We'll see. Also change the tag name from
watchdog to lowmem, since sharkey is kindly taking care of
the back-end to handle this.
Improve how we put processes into low memory states to better
poke things like home and the previous app.
Also clean up some debug output, and add a few new am comment
options for controlling the current debug app.
Change-Id: I562a931a95244a2727bb7a6e1fd80dec259cdae2
...the "Complete action using" dialog
I have never been able to reproduce this consistently, but here is
another stab in the twilight. It looks like during boot we have
a potential race where we could reset the config sequence number after
we had gone through a config change, causing ActivityThread to ignore
a following config change. Maybe this change will help.
Change-Id: I4b731df5fd5c63894ca2e9bd34693b31ab1c0565
This came up from bug #5601885: Memory increase (leak?) in system_server
Stingray MR1
This isn't *really* a leak in the system process -- it is a leak in an
application process that is causing the system process to keep around
a bunch of ActivityRecord objects longer than it should, until that app
process is ultimately killed.
Unfortunately these days leaking an ActivityRecord also often means
leaking a thumbnail, which is a big slab of memory.
So make the activity manager better about this, using a weak reference
from the handle the object has so we can still clean away most of the
state associated with the ActivityRecord even if the client side leaks
its own reference.
Change-Id: Idbab45e09749cdfb54899203da7981e7b3576e25
We are tagging these as "watchdog" to make them visible in the
reporting tools.
Also new am command to kill all background processes, mostly to make
it easier to test this stuff.
Change-Id: Ib9dc4747cd8bd44156fdf11d6a087cd4272203eb
- ActivityManager now keeps track of previous app as you
move across the home app.
- Better debug info about why an activity is being destroyed.
- New performance tests.
Change-Id: I3a5ae7cb1b9f1624c6792a4f6184353f532b8f3b
This is the process that you had previously been interacting with
in the UI before the current one. Treating it specially should
allow us to improve the scenario of switching back and forth
between two apps.
Also add API constent for ICS MR1.
Change-Id: Ib3fe4df36b270be11dfd6b7e8d107c9994058a4d
- IME service now switches between visible and perceptible depending on
whether it is being showm, allowing us to more aggressively free its
memory when not shown.
- The activity display time is no longer delayed by the activity
transition animation.
- New -R (repeat) option for launching activities with the am command.
- Improved some documentation on Loader to be clear about some methods
that apps should not normally call.
- FrameworkPerf test now allows you to select individual tests to run.
Change-Id: Id1f73de66dc93d63212183958a72119ad174318b
Introduce a new concept of "B" services. All running services are
classified as either A or B. B services are later in the LRU list.
Their oom_adj is after the home app. This allows us to better pick
services to kill based on how long they have running, and should
reduce the amount that we end up killing the home app.
This temporarly turns on a debug log when the oom_adj of a process
is changed. Sorry, I know it is noisy. This is needed to try to
track down why some processes are being killed.
Also add a flag to the SyncManager's service binding to allow the
syncing process to be more aggressively killed if it has done UI.
This is to address cases we have seen where sync is causing an 80MB
gmail process to be kept around, preventing other process from running.
Now what will happen is that the syncing process will aggressively be
killed by the system, and can then be restarted in a much lighter-weight
state.
Do a little tweak in the power manager to allow us to still do smooth
brightness changes even when the fancy TV off animation is in use.
And get rid of a debug log in the window manager that was accidentally
left in.
Change-Id: I64a8eeaaa1f096bab29c665fbff804c7f1d029e2
Enabled by setting system property ro.config.headless to 1
This will allow the framework to run without starting activities,
system UI and the keyguard.
Framework can still run services, content providers and broadcast receivers.
Change-Id: I96606609a4ede57a2c4c7fb2b6ff060ebf31e3b4
Signed-off-by: Mike Lockwood <lockwood@android.com>
The basic problem was that at some points during setup wizard, this would
happen:
1. The app's process is killed.
2. The app's process is restarted, but not to actually resume the
setup wizard activity, just to put it in the stopped state.
When doing this, the saved state is cleared but the app will
never provide a new one.
3. The app's process is killed again. At this point, because the
saved state is cleared, the activity is completely removed.
4. Eventually the entire activity stack becomes empty, and a new
setup wizard activity needs to be created as the home app.
There is a combination of bad stuff going on here.
First, why is the process being killed? At this point the setup
wizard is the home app, so it shouldn't be killed. There were two
reasons why this was happening:
- CryptKeeper still was not completely cleanly going away. To fix
this, I removed the check in the activity manager to not allow
an activity to finish if it is the only activity on the stack and
maybe-kindof looks like the home app. This really wasn't necessary
(we always take care of starting a new home activity if we find the
stack is empty), and outright dangerous with all of these things
purporting to be home but not.
- There was an issue in computing the oom_adj where the home app
would not be marked as "not hidden", and if we had to re-compute
its oom adj in the current sequence would then give it an
adjustment as a background process... and with all the processes
we spin through during boot, it quickly got down to background
#16 and killed.
Second, what is going on with the state? This is easier, the code
in the activity manager to create a new activity but put it in the
stopped state was still clearing the saved state. The saved state
should only be cleared when going in to the resumed state. When
going in to the stopped state, we can just keep holding the same
saved state.
Change-Id: I7d21cdcfa082d98ca70c79d9923e29605ee4353e
...dev.bootcomplete flags is set before boot animation is out
Also:
- Fix crash in recent apps if the intent for an old app didn't
happen to have the new task flag set.
- Fix issue where a crash in system UI would cause the crash
dialog to be displayed below it, effectively locking the UI. Now
the crash dialog for persistent processes is shown above everything
else.
Change-Id: I0312001a92beeae5f644c7c3e5c5e19f6716df36
Some services have info that is not readily available any other way. Add
a permission check to those services.
Bug: 5389201
Change-Id: I5a9724ec89e1c11ef7813eeb52a6a05b3ea92af5
...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
