| be4e6aaa0252dd7da28b7aa85beba982538efa46 |
|
07-Jun-2013 |
Dianne Hackborn <hackbod@google.com> |
Initial super-primitive process tracker.
The goal of this is to keep track of what app processes
are doing, to determine who is being abusive, when the system
is getting into memory constrained situations, and help the
user determine how to resolve this.
Right now it doesn't really do any of that, just keeps track
of how long every process has been running since boot.
Also update the activity manager to use "cached" as the terminology
for what it used to interchangeably call hidden and background
processes, and switch ProcessMap over to using ArrayMap.
Change-Id: I270b0006aab1f38e17b7d9b65728679173c343f2
/frameworks/base/services/java/com/android/server/am/UserStartedState.java
|
| 36d337adffa6d1c4c953e83730ad58747f554877 |
|
08-Oct-2012 |
Dianne Hackborn <hackbod@google.com> |
Framework side of issue #7302511: GCM client needs to use new framework API...
...to fix background->shutdown delivery race
Add ACTION_STOPPING and ACTION_STARTING to allow such apps to keep track of
which users are started/stopped, and be involved in the process of stopping
a user.
Also get rid of the scale part of the wallpaper transitions, since it seems
like I have still failed at getting the user switch to wait until the new
wallpaper is displayed.
Change-Id: If7e8fdae3544a9d7987a1b9274dc8b49022f6f62
/frameworks/base/services/java/com/android/server/am/UserStartedState.java
|
| d4ac8d7b3de27a9f0e4c6af2496ca71d794e42d1 |
|
28-Sep-2012 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #7211769 and #7244492, thrash around on #7226656.
Issue #7211769: Crash dialog from background user has non-working "report"
The report button now launches the issue reporter for the correct user.
Also for crashes on background users, either disable the report button,
or simply don't show the dialog depending on the build config.
Issue #7244492: Bugreport button in Quick Settings doesn't actually do anything
Now they do.
Issue #7226656: second user seeing primary user's apps
I haven't had any success at reproducing this. I have tried to tighten up
the path where we create the user to ensure nothing could cause the
user's applications to be accessed before the user it fully created and thus
make them installed... but I can't convince myself that is the actual problem.
Also tightened up the user switch code to use forground broadcasts for all
of the updates about the switch (since this is really a foreground operation),
added a facility to have BOOT_COMPELTED broadcasts not get launched for
secondary users and use that on a few key system receivers, fixed some debug
output.
Change-Id: Iadf8f8e4878a86def2e495e9d0dc40c4fb347021
/frameworks/base/services/java/com/android/server/am/UserStartedState.java
|
| 80a4af2bbc6af42ae605e454bf89558e564f5244 |
|
28-Aug-2012 |
Dianne Hackborn <hackbod@google.com> |
Start implementing concept of "running" users.
The activity manager now keeps track of which users are running.
Initially, only user 0 is running.
When you switch to another user, that user is started so it is
running. It is only at this point that BOOT_COMPLETED is sent
for that user and it is allowed to execute anything.
You can stop any user except user 0, which brings it back to the
same state as when you first boot the device. This is also used
to be able to more cleaning delete a user, by first stopping it
before removing its data.
There is a new broadcast ACTION_USER_STOPPED sent when a user is
stopped; system services need to handle this like they currently
handle ACTION_PACKAGE_RESTARTED when individual packages are
restarted.
Change-Id: I89adbd7cbaf4a0bb72ea201385f93477f40a4119
/frameworks/base/services/java/com/android/server/am/UserStartedState.java
|