Let MetricsService know about some Android Activities

base/metrics/histogram_base.h

Index: base/metrics/histogram_base.h
diff --git a/base/metrics/histogram_base.h b/base/metrics/histogram_base.h
index 11b9a45b3831630f0841fb484988a111460d747b..f3e9b4610772813f5804c1d3c874b1e7e1b21e05 100644
--- a/base/metrics/histogram_base.h
+++ b/base/metrics/histogram_base.h
@@ -56,13 +56,20 @@ class BASE_EXPORT HistogramBase {
 
   enum Flags {
     kNoFlags = 0,
-    kUmaTargetedHistogramFlag = 0x1,  // Histogram should be UMA uploaded.
 
-    // Indicate that the histogram was pickled to be sent across an IPC Channel.
-    // If we observe this flag on a histogram being aggregated into after IPC,
-    // then we are running in a single process mode, and the aggregation should
-    // not take place (as we would be aggregating back into the source
-    // histogram!).
+    // Histogram should be UMA uploaded.
+    kUmaTargetedHistogramFlag = 0x1,
+
+    // Indicates that this is a stability histogram. This flag exists to specify
+    // which histograms should be included in the initial stability log. Please
+    // refer to |MetricsService::PrepareInitialStabilityLog|.
+    kUmaStabilityHistogramFlag = kUmaTargetedHistogramFlag | 0x2,

[Ilya Sherman, 2014/02/08 00:59:49]

It's unfortunate to need to leak this detail into the base layer.  Can we avoid
doing that, perhaps by having a whitelist of which histograms are
stability-targeted?

[Kibeom Kim (inactive), 2014/02/10 22:24:45]

asvitkine@ : Do you have any suggestion? Maybe we can have another
HistogramSnapshotManager::PrepareDeltas(...) function that takes the histogram
names instead of |required_flags|?

[Alexei Svitkine (slow), 2014/02/10 22:48:23]

Adding another function that takes an array of histogram names makes sense to me
(though it should have a different name since overloading is discouraged).

(But I was fine with the previous approach too since the current Flags are
already pretty bad in terms of having base know about things outside of base...)

[Ilya Sherman, 2014/02/11 07:47:27]

Yeah, the flags are already pretty leaky, and are certainly more efficient than
comparing names.  It might be that implementing an efficient solution that
avoids leaking this information is too much work for the payoff that it gives. 
I'm not sure -- I don't have any great ideas right now on how to smoothly
improve on this design, which means that maybe we should keep this approach for
now.

That said, I would probably at least drop the last sentence, which references
the MetricsService -- that's likely to grow stale.

+
+    // Indicates that the histogram was pickled to be sent across an IPC
+    // Channel. If we observe this flag on a histogram being aggregated into
+    // after IPC, then we are running in a single process mode, and the
+    // aggregation should not take place (as we would be aggregating back into
+    // the source histogram!).
     kIPCSerializationSourceFlag = 0x10,
 
     // Only for Histogram and its sub classes: fancy bucket-naming support.