For people who want to annotate their own functions as slow, outside
of just the built-in disk & network stuff.
Change-Id: Ia90e150d1cf7a23a658c091285c1c8bb2d7d9732
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
For apps targetting Honeycomb SDK or above, make network usage on the
main thread (aka event thread, Looper thread, UI thread) be fatal.
If an app is targetting a previous SDK version, they're grandfathered
into the older (lack of) rules.
Bug: 786847
Change-Id: Ia4ae77b8369567ee526c96b930d523bc722b0bc9
The way StrictMode is used during development, just dropboxing
violations, could be a little more optimal, taking the
ActivityManagerService call off the main thread. But we can only do
this safely in the case where that's the only penalty.
Data suggests this call, despite being async, still takes around 30
milliseconds. This isn't a major win, and arguably it might be a
_better_ idea to slow down people's event loops more and further jank
up their animations on violations, but I thought any less overhead
from StrictMode, the better.
Change-Id: Iad9cce1cb4a084fa64abc4b5e1b4f3bff6a08c94
This will be used for StrictMode to annotate violations with
whether or not they janked up an animation.
Change-Id: I5bc691f49b74c45279cd2ae044d2a81dcf1204a9
