Variations seed is pulled from the Java application on the first launch of Chrome

components/variations/variations_seed_store.h

Index: components/variations/variations_seed_store.h
diff --git a/components/variations/variations_seed_store.h b/components/variations/variations_seed_store.h
index cc743d88cd29fdb5caa17e71b38d414d046fec49..53959a8926367d2d770b3a84846843f0e90203f7 100644
--- a/components/variations/variations_seed_store.h
+++ b/components/variations/variations_seed_store.h
@@ -7,6 +7,7 @@
 
 #include <string>
 
+#include "base/callback.h"
 #include "base/compiler_specific.h"
 #include "base/gtest_prod_util.h"
 #include "base/time/time.h"
@@ -75,6 +76,14 @@ class VariationsSeedStore {
   // Registers Local State prefs used by this class.
   static void RegisterPrefs(PrefRegistrySimple* registry);
 
+#if defined(OS_ANDROID)
+  void SetVariationsFirstRunSeedCallback(
+      const base::Callback<void(std::string*, std::string*, std::string*)>&

[Bernhard Bauer, 2015/10/30 09:56:08]

Hm... instead of a single callback that returns three values (where in the
actual implementation the three values seems to be pretty much independent), it
might be cleaner to just make an interface with three methods out of this.

[Steven Holte, 2015/11/02 19:05:40]

They are not really independent, since they all come from a single variations
seed fetch.  A previous version of the CL had them independent as calls of 1
function, and I think this version is a bit cleaner.

[Bernhard Bauer, 2015/11/02 19:10:07]

What I meant was that it looks like doing this with independent methods would
not require much duplication of code – it's just three different calls to read
preferences. Alternatively, if these three values are really meant to be used
together, would it make sense to put them into a struct?

[Alexei Svitkine (slow), 2015/11/02 20:39:21]

They are meant to be used together. I think a struct sounds good, but we'd need
to find a place for it given right now the prefs bridge code doesn't depend on
the variations code. I suggest adding a TODO for this but leaving it as-is for
this CL. And then address in a follow-up CL.

(Bernhard, for context we're trying hard to get this in before the M48 branch
since the data compression folks are planning to use this for a rollout they
have targeted for M48. So I'd rather this code start landing sooner and being
tested by the waterfall, etc. Some minor parts like this can be cleaned post the
initial commit. More important things I think it still makes sense to get right
in this first CL, but in my opinion this can wait for a follow-up CL).

+        callback) {
+    get_variations_first_run_seed_ = callback;
+  }
+#endif  // OS_ANDROID
+
  protected:
   // Note: UMA histogram enum - don't re-order or remove entries.
   enum VerifySignatureResult {
@@ -103,6 +112,10 @@ class VariationsSeedStore {
   // Clears all prefs related to variations seed storage.
   void ClearPrefs();
 
+  // Imports the variations seed data from Java side during the first
+  // Chrome for Android run.
+  void ImportFirstRunJavaSeed();
+
   // Reads the variations seed data from prefs; returns true on success.
   bool ReadSeedData(std::string* seed_data);
 
@@ -134,6 +147,9 @@ class VariationsSeedStore {
   // Keeps track of an invalid signature.
   std::string invalid_base64_signature_;
 
+  base::Callback<void(std::string*, std::string*, std::string*)>
+    get_variations_first_run_seed_;
+
   DISALLOW_COPY_AND_ASSIGN(VariationsSeedStore);
 };