Now the dumpsys battery output will show up in bugreports again.
Change-Id: Id36e87d27e9d3c06dcc17671c81aa1d3fe260d1e
Signed-off-by: Mike Lockwood <lockwood@android.com>
- When shutting down, if the screen goes to sleep there is code
that tries to do a notifyAll without holding the lock:
java.lang.IllegalMonitorStateException: object not locked by thread before notifyAll()
at java.lang.Object.notifyAll(Native Method)
at com.android.server.am.ActivityStack.checkReadyForSleepLocked(ActivityStack.java:776)
at com.android.server.am.ActivityStack$1.handleMessage(ActivityStack.java:282)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:137)
at com.android.server.ServerThread.run(SystemServer.java:603)
- If an invalid Uri object is sent to the system process it can crash because
the Uri class throws an assertion while unmarshalling. Change this to an
IllegalArgumentException so it gets sent back to the caller:
java.lang.AssertionError
at android.net.Uri$PathPart.readFrom(Uri.java:2224)
at android.net.Uri$HierarchicalUri.readFrom(Uri.java:1106)
at android.net.Uri$1.createFromParcel(Uri.java:1689)
at android.net.Uri$1.createFromParcel(Uri.java:1681)
at android.content.IContentService$Stub.onTransact(IContentService.java:53)
at android.content.ContentService.onTransact(ContentService.java:120)
at android.os.Binder.execTransact(Binder.java:338)
at dalvik.system.NativeStart.run(Native Method)
- StrictMode can try to access the first index in the stack crawl of a stack crawl
array of length 0. Not sure why this happens, but make the code more robust:
java.lang.ArrayIndexOutOfBoundsException: length=0; index=0
at android.app.ApplicationErrorReport$CrashInfo.<init>(ApplicationErrorReport.java:341)
at android.os.StrictMode$ViolationInfo.<init>(StrictMode.java:1978)
at android.os.StrictMode$AndroidBlockGuardPolicy.startHandlingViolationException(StrictMode.java:1097)
at android.os.StrictMode$AndroidBlockGuardPolicy.onReadFromDisk(StrictMode.java:1068)
at libcore.io.BlockGuardOs.read(BlockGuardOs.java:137)
at libcore.io.IoBridge.read(IoBridge.java:426)
at java.io.FileInputStream.read(FileInputStream.java:179)
at java.io.InputStream.read(InputStream.java:148)
at com.android.internal.os.ProcessStats.readFile(ProcessStats.java:804)
at com.android.internal.os.ProcessStats.getCpuSpeedTimes(ProcessStats.java:564)
at com.android.internal.os.ProcessStats.getLastCpuSpeedTimes(ProcessStats.java:545)
at com.android.server.am.ActivityManagerService.updateCpuStatsNow(ActivityManagerService.java:1470)
at com.android.server.am.ActivityManagerService.batteryNeedsCpuUpdate(ActivityManagerService.java:1522)
at com.android.internal.os.BatteryStatsImpl$MyHandler.handleMessage(BatteryStatsImpl.java:110)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:137)
at com.android.server.am.ActivityManagerService$AThread.run(ActivityManagerService.java:1302)
(Also fix this code to not cause strict mode to trigger at all, because there is
no need, because this is just reading stuff from /proc.)
- The system seems to crash during boot if it thinks it needs to rotate
the screen, when it is trying to take the freeze snapshot way too early.
There is no need to freeze the screen during boot or if the screen is off:
java.lang.NullPointerException
at android.view.Surface.init(Native Method)
at android.view.Surface.<init>(Surface.java:256)
at com.android.server.wm.ScreenRotationAnimation.<init>(ScreenRotationAnimation.java:91)
at com.android.server.wm.WindowManagerService.startFreezingDisplayLocked(WindowManagerService.java:8758)
at com.android.server.wm.WindowManagerService.startAppFreezingScreenLocked(WindowManagerService.java:3971)
at com.android.server.wm.WindowManagerService.startAppFreezingScreen(WindowManagerService.java:4003)
at com.android.server.am.ActivityRecord.startFreezingScreenLocked(ActivityRecord.java:515)
at com.android.server.am.ActivityStack.ensureActivityConfigurationLocked(ActivityStack.java:3997)
at com.android.server.am.ActivityManagerService.updateConfigurationLocked(ActivityManagerService.java:12535)
at com.android.server.am.ActivityManagerService.updateConfiguration(ActivityManagerService.java:12439)
at com.android.server.wm.WindowManagerService.systemReady(WindowManagerService.java:6161)
at com.android.server.ServerThread.run(SystemServer.java:521)
Change-Id: I85062bb5f6b0909a0f52feedaa75e7611d9d7fbd
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
Add ActivityManager.getAllPackageUsageStats which returns
the PkgUsageStats object for all packages.
In UsageStatsService, remember the last resume time of each component, and
add that info to PkgUsageStats instances.
ApplicationProvider will use getAllPackageUsageStats and the new field
in PkgUsageStats to set the new SearchManager column
SUGGEST_COLUMN_LAST_USAGE_HINT for requests with the GLOBAL_SEARCH
permission.
Change-Id: I80e9b127410ed0d528515d2256787f30a953e9b0
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
Make the force close dialogs consistent with both the new rules for
wizardy-button bar UI flows and the previous arrangement that people
are used to. Force close = negative/back/cancel, Report =
positive/next/ok.
Change-Id: I212ba172f8076238a1833100b025b6e25a538a65
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
...will only launch when held in portrait mode.
There was a bug in the window manager that caused all of the careful code to
update the configuration in sync with movements between activities to break.
Now it is fixed, so this app works, and we no longer see the bad slow orientation
changes when switching between activities that want to be in different
orientations.
Change-Id: I5d93f99649849bdaca2e8bebade6b91b8b6cf645