Record Mobile Operator ID in UMA report. This is Android only for now.

chrome/common/metrics/proto/system_profile.proto

Index: chrome/common/metrics/proto/system_profile.proto
diff --git a/chrome/common/metrics/proto/system_profile.proto b/chrome/common/metrics/proto/system_profile.proto
index fd339ec5d26db48c249c9d30b0d7827b1cc0f50a..7cc559487b29e6ed52bcc0496270860173b613a3 100644
--- a/chrome/common/metrics/proto/system_profile.proto
+++ b/chrome/common/metrics/proto/system_profile.proto
@@ -287,6 +287,11 @@ message SystemProfileProto {
     }
     // The physical layer mode of the associated wifi access point, if any.
     optional WifiPHYLayerProtocol wifi_phy_layer_protocol = 4;
+
+    // MCC+MNC (mobile country code + mobile network code) of the
+    // the current registered mobile network operator.
+    // If there is no mobile network, the value is the empty string.

[Alexei Svitkine (slow), 2014/04/23 17:58:49]

How about when it changes during the the course of an UMA log?

I think in that case it would be best to also report an empty string. This would
require a bit more involved changes to the metrics code - e.g. keeping a
timestamp of when it changed and compare that to the start of the log. If you
look at the code for synthetic trials, they do something similar.

[bolian, 2014/04/24 00:59:24]

Is MetricsLog::RecordEnvironment eventually called when I call, for example,
UMA_HISTOGRAM_COUNTS, so that the environment is recorded for that particular
metric?

Or, MetricsLog::RecordEnvironment is actually called when reporting the metrics
through WiFi?

If it is the first case, I think the chance to record a metric during network
transition is low, and we can accept some errors. If it is the latter case, I
have to reconsider.

+    optional string mcc_mnc = 5;
   }
   optional Network network = 13;