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
Merge commit 'b4157a432cf791906d5b2f6d187f1767357a51bb' into gingerbread-plus-aosp
* commit 'b4157a432cf791906d5b2f6d187f1767357a51bb':
StrictMode: fix docs to actually compile and add a utility method.
Yes, this is a last minute public API change, but I'm already getting
a lot of inquiries about how to use StrictMode on a GB device but
targetting Eclair or Froyo. I'd like a simple answer involving
reflection, but the current API is too painful to use via reflection.
I imagine this will be a common request, and it's much easier for us
to write a little blog post about trying it out if there's an easy way
to use it with reflection.
Change-Id: I1f21aaac7e61e5e90d1e4facc0c787d8daf089b1
Merge commit '13e46665ff69c1a37880762d7d611aacdf02dac7'
* commit '13e46665ff69c1a37880762d7d611aacdf02dac7':
Work on issue #3101415: Crespo apps seem to have their UID changed over time.
