Chromecast: don't try to upload crash immediately.

chromecast/base/java/src/org/chromium/chromecast/base/ChromecastConfigAndroid.java

Index: chromecast/base/java/src/org/chromium/chromecast/base/ChromecastConfigAndroid.java
diff --git a/chromecast/base/java/src/org/chromium/chromecast/base/ChromecastConfigAndroid.java b/chromecast/base/java/src/org/chromium/chromecast/base/ChromecastConfigAndroid.java
new file mode 100644
index 0000000000000000000000000000000000000000..6b547997aec292e08e04ca1070231f6a0fd17631
--- /dev/null
+++ b/chromecast/base/java/src/org/chromium/chromecast/base/ChromecastConfigAndroid.java
@@ -0,0 +1,49 @@
+// Copyright 2015 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+package org.chromium.chromecast.base;
+
+import android.content.Context;
+
+import org.chromium.base.CalledByNative;
+import org.chromium.base.JNINamespace;
+
+/**
+ * JNI wrapper class for calls from ChromecastConfigAndroid.
+ */
+@JNINamespace("chromecast::android")
+public final class ChromecastConfigAndroid {
+
+    private static CastSettingsManager sSettingsManager;

[byungchul, 2015/06/11 17:15:00]

So, multiple SettingsManager is created here and in
MediaShellCastReceiverService.java. Why not pass SettingsManager instance in
CastBrowserHelper.initializeBrowser()?

[gunsch, 2015/06/12 00:30:30]

Each CastSettingsManager instance can provide a listener for different things.
Why make it a singleton? I don't see a lot of upside, and there are the usual
reasons to avoid singletons.

We could definitely rewrite CastSettingsManager to be able to register multiple
listeners instead of just taking one in the ctor. Do you think that would be
cleaner?

Even in that case it would probably still make sense for the render process to
create its own CastSettingsManager instance.

[byungchul, 2015/06/12 05:57:00]

Once we merged preference and CastSettingsManager, api could be changed a lot.
Let's see how it goes.

By the way, is it really necessary for renderer process to access
CastSettingsManager? It looks like to call canSendUsageStats(). Can't it just
return true for renderer process since browser process removes dump files? Or,
passing a command line flag?

[gunsch, 2015/06/12 16:54:52]

No, it can't just return true for renderer.

Value can change over time, so I'd rather use the source of truth when it's
available. Breakpad calls into asking if upload is allowed before writing out
the crash dump. You could imagine a (unlikely, but possible) case where the
crash dump is written while collecting usage data is off, then the user turns
usage data on before the crash uploader runs again.

What API do you imagine using? Are you proposing something like a single
instance per process where listeners can be added/removed, e.g.

// Only one of these may be called per process
public static CastSettingsManager getPrivilegedSettingsManager(Context);
public static CastSettingsManager getSandboxedSettingsManager(Context);

public void addListener(Listener)
public void removeListener(Listener)

+
+    public static void initializeForBrowser(Context applicationContext) {
+        sSettingsManager = CastSettingsManager.createPrivilegedCastSettingsManager(
+                applicationContext,
+                new CastSettingsManager.OnSettingChangedListener() {
+                    @Override
+                    public void onSendUsageStatsChanged(boolean enabled) {
+                        nativeSetSendUsageStatsEnabled(enabled);
+                    }
+                });
+    }
+
+    /**
+     * Returns the appropriate SettingsManager instance. In renderer process, CastSettingsManager
+     * is not initialized on startup, but is still needed lazily to retrieve crash reporting
+     * information.
+     */
+    private static CastSettingsManager getSettingsManager(Context context) {
+        if (sSettingsManager == null) {
+            sSettingsManager = CastSettingsManager.createSandboxedCastSettingsManager(context);
+        }
+        return sSettingsManager;
+    }
+
+    @CalledByNative
+    public static boolean canSendUsageStats(Context context) {
+        return getSettingsManager(context).isSendUsageStatsEnabled();
+    }
+
+    private static native void nativeSetSendUsageStatsEnabled(boolean enabled);
+}