More work on issue #17656716: Unhandled exception in Window Manager
Fix Slog.wtf to not acquire the activity manager lock in its code
path, so that it can never deadlock. This was the original intention
of it, but part was missed.
Now we can put back in the code to detect when strict mode data is
getting large (a little more targeted now to the actual problem),
and use Slog.wtf to report it. And as a bonus, when this happens
we will now clear all of the collected violations, to avoid getting
in to the bad case where IPCs start failing. So this should be
good enough for L to fix the problem, with wtf reports for us to
see if the underlying issue is still happening.
Finally, switch a butch of stuff in the system process from Log.wtf
to Slog.wtf, since many of those are deadlocks waiting to happen.
Oh and fix a crash in the settings provider I noticed in APR.
Change-Id: I307d51b7a4db238fd1e5fe2f3f9bf1b9c6f1c041
diff --git a/services/core/java/com/android/server/am/BroadcastQueue.java b/services/core/java/com/android/server/am/BroadcastQueue.java
index 4e554eb..e01b983 100644
--- a/services/core/java/com/android/server/am/BroadcastQueue.java
+++ b/services/core/java/com/android/server/am/BroadcastQueue.java
@@ -901,7 +901,7 @@
Slog.w(TAG, "Exception when sending broadcast to "
+ r.curComponent, e);
} catch (RuntimeException e) {
- Log.wtf(TAG, "Failed sending broadcast to "
+ Slog.wtf(TAG, "Failed sending broadcast to "
+ r.curComponent + " with " + r.intent, e);
// If some unexpected exception happened, just skip
// this broadcast. At this point we are not in the call