Use kMetricsReportingEnabled instead of kStatsReporingPref on metrics side

chrome/browser/chrome_browser_main.cc

Index: chrome/browser/chrome_browser_main.cc
diff --git a/chrome/browser/chrome_browser_main.cc b/chrome/browser/chrome_browser_main.cc
index 010d0cbeec7af03358db7dd5723bf48f70341f0d..e4da99171bc603072de2a6b6c7ff90508160ab51 100644
--- a/chrome/browser/chrome_browser_main.cc
+++ b/chrome/browser/chrome_browser_main.cc
@@ -62,6 +62,7 @@
 #include "chrome/browser/media/media_capture_devices_dispatcher.h"
 #include "chrome/browser/memory/tab_manager.h"
 #include "chrome/browser/metrics/field_trial_synchronizer.h"
+#include "chrome/browser/metrics/metrics_reporting_state.h"
 #include "chrome/browser/metrics/thread_watcher.h"
 #include "chrome/browser/nacl_host/nacl_browser_delegate_impl.h"
 #include "chrome/browser/net/crl_set_fetcher.h"
@@ -732,6 +733,16 @@ void ChromeBrowserMainParts::SetupMetricsAndFieldTrials() {
   // Register a synthetic field trial for the sampling profiler configuration
   // that was already chosen.
   sampling_profiler_config_.RegisterSyntheticFieldTrial();
+
+#if defined(OS_CHROMEOS)
+  // Set kMetricsReportingEnabled based on kStatsReportingPref device setting as
+  // it is more reliable for Chrome OS.

[Mattias Nissler (ping if slow), 2015/10/28 09:51:15]

suggestion: s/it is more reliable for Chrome OS/it is the source of truth on
Chrome OS/.

[gayane -on leave until 09-2017, 2015/10/28 15:00:07]

Done.

+  bool enable_metrics = false;
+  chromeos::CrosSettings::Get()->GetBoolean(chromeos::kStatsReportingPref,
+                                            &enable_metrics);

[Mattias Nissler (ping if slow), 2015/10/28 09:51:15]

I'd expect an observer to be installed here to re-sync the pref after the device
setting changes?

[gayane -on leave until 09-2017, 2015/10/28 15:00:06]

you mean besides initialization? My understanding is that there is no scenario
when kStatsReportingPref will change which needs to also affect
kMetricsReportingEnabled.

Now kStatsReportingPref changes its value only in two cases. 
 - First when policy is applied. in this case kMetricsReportingEnabled gets
directly changed by policy
 - Second when user changes kMetricsReportingEnabled then kStatsReportingPref
gets updated accordingly.

[Mattias Nissler (ping if slow), 2015/10/29 10:06:14]

I guess you're referring to the CrosSettings::SetBoolean call in
browser_options_handler.cc here, correct? While in theory what you say is
correct, the assumption that whatever Chrome writes is fragile. I'd prefer a
solution that enables/disables metrics reporting based on the actual ground
truth value reported by device settings, and not just Chrome's idea what it
should be.

For example, we do have some code in session_manager that may sanitize certain
device settings. While it currently doesn't touch the metrics reporting flag,
the existence of that code shows that second-guessing the behavior of device
settings is not the best of ideas.

[Alexei Svitkine (slow), 2015/10/29 17:04:14]

Can the observer change be done in a later CL? I think it would be a bit
non-trivial, since it also requires toggling UMA service state and other things,
and for that kind of more complicated logic we probably need test coverage. How
about having a TODO comment with an associated crbug for this CL? Especially
that you say it can't change right with the current code right now.

[Mattias Nissler (ping if slow), 2015/11/02 11:09:58]

Note that the old code does handle device settings changes in
device_settings_provider.cc and switches metrics reporting state appropriately,
so this CL would essentially be a step back on this aspect. For this reason, I'm
feeling a bit uncomfortable with a bug + TODO - how about we make the functional
change as part of this CL and then postpone test coverage to a follow-up?

+  InitiateMetricsReportingChange(enable_metrics,
+                                 OnMetricsReportingCallbackType());
+#endif
 }
 
 // ChromeBrowserMainParts: |SetupMetricsAndFieldTrials()| related --------------