[Cronet] Hook up library loader, system proxy and network change notifier to async api.

components/cronet/android/java/src/org/chromium/net/CronetLibraryLoader.java

+// Copyright 2014 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.net;
+
+import android.content.Context;
+import android.os.ConditionVariable;
+import android.os.Handler;
+import android.os.Looper;
+
+import org.chromium.base.JNINamespace;
+
+/**
+ * CronetLibraryLoader loads and initializes native library on main thread.
+ */
+@JNINamespace("cronet")
+public class CronetLibraryLoader {
+    /**
+     * Synchronize access to mInitComplete and initialization routine.
+     */
+    private static final Object sLoadAndInitLock = new Object();
+    private static boolean sLoadAndInitComplete = false;
+    private static final ConditionVariable sInitialized = new ConditionVariable();
+
+    public static void loadAndInitialize(
+            final Context context, final UrlRequestContextConfig config) {
+        synchronized (sLoadAndInitLock) {
+            if (sLoadAndInitComplete) {
+                return;
+            }
+            System.loadLibrary(config.libraryName());
+            // Init native Chromium URLRequestContext on Main UI thread.
+            Runnable task = new Runnable() {
+                public void run() {
+                    NetworkChangeNotifier.init(context);
+                    // Registers to always receive network notifications. Note
+                    // that this call is fine for Cronet because Cronet
+                    // embedders do not have API access to create network change
+                    // observers. Existing observers in the net stack do not
+                    // perform expensive work.
+                    NetworkChangeNotifier.registerToReceiveNotificationsAlways();
+                    nativeCronetInitOnMainThread(context);

[xunjieli, 2015/01/05 14:48:03]

I wonder whether we should do "nativeCronetInitOnMainThread"  in front of
"NetworkChangeNotifier.init(context);" and
"NetworkChangeNotifier.registerToReceiveNotificationsAlways();"

[mef, 2015/01/05 16:59:21]

Good question. I've copied it from ChromiumUrlRequestContext, which seems to
initialize NCN first, and 
adapted second, but I'm not sure about correct sequence. Adding Paul to comment.

[pauljensen, 2015/01/06 17:38:40]

I don't think the order matters.  The only advantage I can see from swapping
them is that the NetworkChangeNotifier.init() call is redundant with the
nativeCronetInitOnMainThread() call, so if they were swapped, the init() call
could be removed.
I'd weakly recommend doing whatever Chrome for Android does but I'm not sure
what that is as I can't make much sense of their initialization code as it's
quite complicated.

+                    sInitialized.open();
+                }
+            };
+            // Run task immediately or post it to the UI thread.
+            if (Looper.getMainLooper() == Looper.myLooper()) {
+                task.run();
+            } else {
+                new Handler(Looper.getMainLooper()).post(task);
+            }
+            // Wait for initialization to complete on the main thread.
+            sInitialized.block(5000);

[xunjieli, 2015/01/05 14:48:03]

Why do we need to wait for initialization to complete? I thought we made the
initialization asynchronous, and all posted tasks will guaranteed to happen
after initialization anyway (through RunTaskAfterContextInitOnNetworkThread).

[mef, 2015/01/05 16:59:21]

The goal is to prevent race in case of concurrent initialization. 
I've reworked it to remove the wait. Done?

+            sLoadAndInitComplete = true;
+        }
+    }
+
+    // Native methods are implemented in cronet_loader.cc.
+    private static native long nativeCronetInitOnMainThread(Context context);
+}