🍈 Unify application context usage.

base/android/java/src/org/chromium/base/ContextUtils.java

 // 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.base;
 
 import android.content.Context;
 
 import org.chromium.base.annotations.CalledByNative;
 import org.chromium.base.annotations.JNINamespace;
@@ skipping 16 matching lines @@
      * Do not downcast the context returned by this method to Application (or any subclass). It may
      * not be an Application object; it may be wrapped in a ContextWrapper. The only assumption you
      * may make is that it is a Context whose lifetime is the same as the lifetime of the process.
      */
     public static Context getApplicationContext() {
         assert sApplicationContext != null;
         return sApplicationContext;
     }
 
     /**
-     * Initialize the Android application context.
+     * Initializes the java application context.
+     *
+     * @param appContext The application context.
+     */
+    public static void setApplicationContext(Context appContext) {
+        // TODO(wnwen): Figure out how to fix this for JUnit tests. Currently they fail this assert

[Torne, 2016/04/13 15:38:38]

Why weren't the tests having this problem before?

[Peter Wen, 2016/04/13 18:49:20]

It's due to BaseChromiumApplication setting this up. Removing that fixed this.

+        //     due to repeatedly calling onCreate in the base application and keeping global state.
+        //assert sApplicationContext == null || sApplicationContext == appContext;
+        initJavaSideApplicationContext(appContext);
+    }
+
+    /**
+     * Initialize the native Android application context to be the same as the java counter-part.
      *
      * Either this or the native equivalent base::android::InitApplicationContext must be called

[Torne, 2016/04/13 15:38:38]

Not sure the comment here makes sense any more; it's not this function that
binaries need to call, but setApplicationContext, no?

[Peter Wen, 2016/04/13 18:49:20]

Updated comments.

      * once during startup. JNI bindings must have been initialized, as the context is stored on
      * both sides.
      */
+    public static void initApplicationContextForNative() {
+        assert sApplicationContext != null;
+        nativeInitNativeSideApplicationContext(sApplicationContext);
+    }
+
+    // TODO(wnwen): Remove when all callers are migrated to new methods as needed.
     public static void initApplicationContext(Context appContext) {
-        assert appContext != null;
-        assert sApplicationContext == null || sApplicationContext == appContext;
-        initJavaSideApplicationContext(appContext);
-        nativeInitNativeSideApplicationContext(appContext);
+        setApplicationContext(appContext);
+        initApplicationContextForNative();
     }
 
     /**
      * JUnit Robolectric tests run without native code; allow them to set just the Java-side
      * context. Do not use in configurations that actually run on Android!
+     *
+     * TODO(wnwen): These calls can now be safely removed.
      */
     public static void initApplicationContextForJUnitTests(Context appContext) {
         initJavaSideApplicationContext(appContext);
     }
 
+
     @CalledByNative
     private static void initJavaSideApplicationContext(Context appContext) {
         sApplicationContext = appContext;
     }
 
     private static native void nativeInitNativeSideApplicationContext(Context appContext);
 }