Also, changes to make this testable with CTS:
-- special PENALTY_DEATH StrictMode fast path that doesn't use
the Looper idling to "time" the violation. Only used when
death is the only violation,
-- make PENALTY_DEATH throw a RuntimeException instead of
killing its process with a signal. this means we can catch
it in CTS tests, but it's also more consistent with
PENALTY_NETWORK_DEATH in Honeycomb.
-- make FileUtils.getFileStatus() invoke StrictMode, which isn't
(yet?) aware of I/O in native code. so help it out.
CTS test for MODE_MULTI_PROCESS is in I6154edab
Change-Id: Icf93f9dfb0ece06b16781e4803dd2c17df3cf1b3
Includes some other small fixes to battery collection and a few
other things.
Output of package info looks like this:
5,0,i,uid,1000,com.android.settings
5,0,i,uid,1000,com.android.providers.subscribedfeeds
5,0,i,uid,1000,com.android.providers.settings
5,0,i,uid,1000,com.android.server.vpn
5,0,i,uid,1000,android
5,0,i,uid,1000,com.android.systemui
5,0,i,uid,1000,com.google.android.backup
5,0,i,uid,1001,com.android.phone
5,0,i,uid,1001,com.android.providers.telephony
5,0,i,uid,1022,com.android.nfc
5,0,i,uid,10021,com.google.android.location
5,0,i,uid,10021,com.google.android.syncadapters.calendar
5,0,i,uid,10021,com.google.android.gsf
5,0,i,uid,10021,com.google.android.syncadapters.contacts
5,0,i,uid,10026,com.android.providers.downloads.ui
5,0,i,uid,10026,com.android.providers.media
5,0,i,uid,10026,com.android.providers.drm
5,0,i,uid,10026,com.android.providers.downloads
5,0,i,uid,10032,com.android.launcher
5,0,i,uid,10039,com.google.android.gm
5,0,i,uid,10041,com.google.android.gallery3d
5,0,i,uid,10049,com.android.providers.calendar
Change-Id: I9e38f254eef146339113ad270f5c6e8b60fb7a1d
For people who want to annotate their own functions as slow, outside
of just the built-in disk & network stuff.
Change-Id: Ia90e150d1cf7a23a658c091285c1c8bb2d7d9732
To monitor the dropbox an application have to either poll the dropbox
and keep track of all entries or observ the /data/system/dropbox
directory. The later requires that the application runs as system-user.
This commit adds that a broadcast intent is sent when something is written
to the dropbox and an application can just listen on this intent and
then reads the entry with help of the DropboxManager class.
The application have to hold the permission android.permission.READ_LOGS
to get the intent.
Change-Id: I1f77f206a243df69f4ed5306078c47f7bf6181ec
The goal is to fix a bunch of fragment-related bugs caused by various
things trying to do fragment transactions after onPause()... which
currently throws an exception, since this is after the activity's state
has been saved so the new fragment state can be lost.
The basic change is relatively simple -- we now consider processes
hosting paused or stopping activities to be unkillable, and the client
code now does the onSaveInstanceState() as part of stopping the
activity.
For compatibility, if an app's targetSdkVersion is < HONEYCOMB, the
client side will still call onSaveInstanceState() prior to onPause()
and just hold on to that state until it needs to report it in once
being stopped.
Also included here is a change to generate thumbnails by taking
screenshots. The code for generating thumbnails by re-rendering
the view hierarchy is thus removed.
Change-Id: Iac1191646bd3cadbfe65779297795f22edf7e74a
Dalvik now exposes a distinction between "packed" and regular opcode
values. The packed values are more densely defined in the range 0-0x1ff,
whereas the regular values are sparsely defined across the range 0-0xffff.
The only current use for packed values at this level is in opcode
usage reporting, but their use may expand over time.
Change-Id: Ie783b90cb2dcb9df8f3eb19a7c708a53906fdbe4
This makes Debug not hard code the number of opcodes and includes an
api-update of other opcode-related changes done in dalvik.system.
Change-Id: I70d22e1c710f224d75a22e319916724aea53f78d
Don't wait for animations to finish before clicking stopwatch. (see
comments in the patch for details)
Change-Id: I73f87b2b787d6db19deb0171a2457ff5fc875d3d
Seen once in an eng build. Could in theory happen if there was a
violation in the system server before the activity manager was
registered.
Change-Id: I785f06848af0e2af4657be3a8edbbd658eeb3cf2
Issues around threading of animations and AnimatorSet bugs are
fixed in this change. Unrelated fixes to javadocs in other
framework classes are also part of the change.
Change-Id: I35f7e03ffdec9143bc2eb155e8f9384798ad35b3
To be clear, the dropbox violations were already async in the
ActivityManager, but the Binder call was often 30 ms anyway.
This optimization was already done for per-thread violations earlier,
but was never done for VM-wide violations because they weren't common,
until CloseGuard came about. Now that CloseGuard fires a lot, apply
the same optimization to VM-wide violations.
This CL also addresses a concern of Dianne's earlier of too many
threads being outstanding. So now there's a paranoia check with an
upper bound on how many outstanding ActivityManager calls are
in-flight.
Change-Id: I95e0816105ab862f0f241052b149c9a46a70ce9c
Thread penalties were just dropboxing, but VM penalties were both
dropboxing *and* logging, and most annoyingly.
Change-Id: Ifc64b642dd0e2b17f0234ce3724650489883f62b
StrictMode now replaces the default CloseGuard.Reporter with one that
calls onVmPolicyViolation, which is a renamed version of
onSqliteObjectLeaked.
Change-Id: Iea980662e2ee91939960c83b8768a8172379617a
When handling large images during an update of a widget,
we can run out of memory in the Binder thread. This will
cause an OutOfMemoryError to be thrown. When an Error is
thrown in the Binder thread, the entire system will crash.
This was fixed by catching this OutOfMemoryError and instead
throw a RuntimeException to keep the system alive.
Change-Id: If27199676c6f8aef23fb249be1197ca5dfe0fe99
In additional to adding the StringMode API for controling CloseGuard,
this checkin fixes several CloseGuard issues found booting a device.
Bug: 3041575
Change-Id: I4dffd184f49438d6d477ed81a1c2a2a5b56cc76b
