ProcessStats is now called ProcessCpuTracker.
ProcessTracker is now ProcessStatsService, and its inner State
class is broken out into a separate top-level ProcessStats class.
This ProcessStats is moved to the framework, so we will be able
to use it elsewhere.
Change-Id: I6a127bcb835b6b474b72647c0b99b82c2137e5c5
The activity manager now keeps a new "process state" for
each process, indicating the general execution and memory
state of the process. This closely follows the out-of-memory
adjustment and scheduling class that it currently tracks,
but roles these together (plus a little more info) into one
more semantically meaningful number.
This value is reported to each process as it changes, so they
can do things like tune the Dalvik garbage collector to match
the current process state.
I think I should also switch to this for process states. It
will give is more meaningful divisions of time for each process.
Also fix a problem in the activity stack where the previous
process was not being set correctly when moving between
activity stacks.
Change-Id: I598b1667dc46547f8fadae304e210c352cc9d41f
The new location monitoring op is to tell us when an application
is monitoring for any location changes. It may be useful information
in addition to the more explicitly information about when location
data actually goes to the app.
Also make parts of AppOpsManager public for use by gcore. It is
not available to third party apps.
Change-Id: Ib639f704258ffdd7f3acd7567350ed2539da628a
We now keep track of when each process is running, batched
by the current memory status of the device. In addition,
the stats are organized by package first, and then processes
associated with each package inside of that. Finally, we
also keep track of the overall time spent in each memory
status.
This should start to actually get us to some information
we can reach some conclusions about. The total time spent
in each memory status gives us some indication of how much
we are running while memory is low; the new package organization
batched by memory status lets us see what packages have
what processes running when memory is low.
Change-Id: I389d62d39d115a846126cf354e4c20070d8f1180
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
Protect app widget broadcasts from abuse.
In this case the app was sending an APPWIDGET_UPDATE broadcast
without specifying a target, which (a) should not be allowed (you
should not be able to send updates to other apps), and (b) resulted
in every single potential app widget in the system being launched...
which was about 75 of them.
Change-Id: I9d48733610ce6d5a7c32e69a3e06b9f33bd79a34
...android.os.Parcel.nativeAppendFrom(Native Method)
The failing stack trace is:
11-20 20:29:04.365 19154 19170 E AndroidRuntime: java.lang.IllegalArgumentException
11-20 20:29:04.365 19154 19170 E AndroidRuntime: at android.os.Parcel.nativeAppendFrom(Native Method)
11-20 20:29:04.365 19154 19170 E AndroidRuntime: at android.os.Parcel.appendFrom(Parcel.java:428)
11-20 20:29:04.365 19154 19170 E AndroidRuntime: at android.os.Bundle.writeToParcel(Bundle.java:1613)
11-20 20:29:04.365 19154 19170 E AndroidRuntime: at android.os.Parcel.writeBundle(Parcel.java:605)
11-20 20:29:04.365 19154 19170 E AndroidRuntime: at android.location.Location.writeToParcel(Location.java:903)
11-20 20:29:04.365 19154 19170 E AndroidRuntime: at android.os.Parcel.writeParcelable(Parcel.java:1254)
11-20 20:29:04.365 19154 19170 E AndroidRuntime: at android.os.Parcel.writeValue(Parcel.java:1173)
11-20 20:29:04.365 19154 19170 E AndroidRuntime: at android.os.Parcel.writeMapInternal(Parcel.java:591)
11-20 20:29:04.365 19154 19170 E AndroidRuntime: at android.os.Bundle.writeToParcel(Bundle.java:1619)
11-20 20:29:04.365 19154 19170 E AndroidRuntime: at android.os.Parcel.writeBundle(Parcel.java:605)
11-20 20:29:04.365 19154 19170 E AndroidRuntime: at android.location.Location.writeToParcel(Location.java:903)
11-20 20:29:04.365 19154 19170 E AndroidRuntime: at android.os.Parcel.writeParcelable(Parcel.java:1254)
11-20 20:29:04.365 19154 19170 E AndroidRuntime: at android.os.Parcel.writeValue(Parcel.java:1173)
11-20 20:29:04.365 19154 19170 E AndroidRuntime: at android.os.Parcel.writeMapInternal(Parcel.java:591)
11-20 20:29:04.365 19154 19170 E AndroidRuntime: at android.os.Bundle.writeToParcel(Bundle.java:1619)
11-20 20:29:04.365 19154 19170 E AndroidRuntime: at android.os.Parcel.writeBundle(Parcel.java:605)
11-20 20:29:04.365 19154 19170 E AndroidRuntime: at android.content.Intent.writeToParcel(Intent.java:6660)
11-20 20:29:04.365 19154 19170 E AndroidRuntime: at android.app.ApplicationThreadProxy.scheduleReceiver(ApplicationThreadNative.java:763)
11-20 20:29:04.365 19154 19170 E AndroidRuntime: at com.android.server.am.BroadcastQueue.processCurBroadcastLocked(BroadcastQueue.java:230)
11-20 20:29:04.365 19154 19170 E AndroidRuntime: at com.android.server.am.BroadcastQueue.processNextBroadcast(BroadcastQueue.java:777)
This is odd because where we do Bundle.writeToParcel(), we are just writing the Parcel
we have with its current length. There is no way this should be able to fail like this...
unless the Bundle is changed while we are running?
Hm.
It looks like the location manager is holding on to Location objects which have a
Bundle of extras. It is that Bundle of extras that the crash is happening on.
And the bundle extras can be changed as it operates. And there are places where
the raw Location object is returned from the location manager, which means the
caller can be olding on to a Location object whose extras can be changed at any
time by other threads in the location manager.
So that seem suspicious.
This change should take care of all these places in the location manager, by
making sure to copy the location object before it goes out of the location
manager.
In addition, add some code to the activity manager to not bring down the entire
system if there is a problem trying to send one of these broadcasts. There is
no need, we can just skip the broadcast as bad.
Change-Id: I3043c1e06f9d2931a367f831b6a970d71b0d0621
...phase & callback API
I realized there were a few things wrong with what was there. The new
ACTION_USER_STARTING was not being sent for the first user at boot, and
there was an existing problem where ACTION_USER_STARTED was sent every
time there was a user switch.
Also improved some debug output of broadcasts to make it easier to see
what is going on in this stuff, and better reporting of why a service
couldn't be started.
Change-Id: Id8a536defbbad1f73d94a37d13762436b822fbe3
Add a new call to the activity manager for the input dispatcher
to report about any pid having an ANR. This has a new feature
where it can also tell the activity manager that it is above the
system alert layer, so the activity manager can pop its ANR dialog
on top of everything if it needs to. (Normally we don't want
these dialogs appearing on top of the lock screen.)
Also fixed some debugging stuff here and there that was useful
as I was working on this -- windows now very clearly include
their uid, various system dialogs now have titles so you know
what they are in the window manager, etc.
Change-Id: Ib8f5d29a5572542cc506e6d338599ab64088ce4e
...Forground Sometimes Doesn't Take
The main change here is a one-liner in ActiveServices to check the
uid when deciding whether to remove an item from mPendingServices.
This could cause the problem being seen -- if the same service for
two users is starting at the same time, the second one would blow
away the pending start of the first one. Unfortunately I have had
trouble reproducing the bug, so I don't know if this is actually
fixing it. It's a bug, anyway.
The reason so much has changed here is because I spread around
logging and printing of the user ID associated with operations and
objects to make it easier to debug these kind of multi-user things.
Also includes some tweaks to the oom manager to allow more background
processes (I have seen many times in logs where we thrash through
processes because the LRU list is too short), plus to compensate an
additional time-based metric for when to get rid of background processes,
plus some new logic to try to help things like Chrome keep around
their service processes.
Change-Id: Icda77fb2a1dd349969e3ff2c8fff0f19b40b31d3
New API to register as an explicit user, which allows you to
also select ALL to see broadcasts for all users.
New BroadcastReceiver API to find out which user the broadcast
was sent to.
Use this in app widget service to handle per-user package broadcasts
and boot completed broadcasts correctly.
Change-Id: Ibbe28993bd4aa93900c79e412026c27863019eb8
- You can now use android:singleUser with receivers and providers.
- New API to send ordered broadcasts as a user.
- New Process.myUserHandle() API.
For now I am trying out "user handle" as the name for the numbers
representing users.
Change-Id: I754c713ab172494bb4251bc7a37a17324a2e235e
- Expose the existing Context.sendBroadcast() as
Context.sendBroadcastAsUser().
- Add new android:singleUser attribute for services.
- Add new INTERACT_ACROSS_USERS_FULL permission for full
system-level access to cross-user interface (allows
sendBroadcastAsUser() to send to any receiver).
- Add new INTERACT_ACROSS_USERS_FULL permission for
more restricted cross-user interaction: this is required
for android:singleUser, and allows you to use
sendBroadcastAsUser() but only to send to your own
receivers.
Change-Id: I0de88f6718e9505f4de72e3f45d29c0f503b76e9
An intent is launched in a singleton process if the process is persistent
and the resolved activity/service/etc is not requested to run in a different
process.
Change-Id: I1463e73a76bc8bde4185f9cf4395edb47515841d
Packages can be enabled/disabled per user.
This requires maintaining stopped/launched states and
enabled / disabled components and packages per user.
Refactored pm.Settings and PackageSettingsBase to keep
track of states per user.
Migrated the stopped-packages.xml to users/<u>/package-restrictions.xml
Changed intent resolution to handle individual user restrictions.
Bunch of IPackageManager calls now have a userId argument.
Make AppWidgetService handle removals of packages.
Added some tests for pm.Settings and PackageManager.
Change-Id: Ia83b529e1df88dbcb3bd55ebfc952a6e9b20e861
