Split JNI init so native library preloading dosn't cause native init.

base/android/library_loader/library_loader_hooks.cc

Index: base/android/library_loader/library_loader_hooks.cc
diff --git a/base/android/library_loader/library_loader_hooks.cc b/base/android/library_loader/library_loader_hooks.cc
index 473883c5e7cc256f3d51f4bcbdd92604ae8fc2de..621575c3f71d6fb9942a8ab7286df1e54942856f 100644
--- a/base/android/library_loader/library_loader_hooks.cc
+++ b/base/android/library_loader/library_loader_hooks.cc
@@ -21,6 +21,7 @@ namespace {
 base::AtExitManager* g_at_exit_manager = NULL;
 const char* g_library_version_number = "";
 LibraryLoadedHook* g_registration_callback = NULL;
+NativeInitializationHook* g_native_initialization_hook = NULL;
 
 enum RendererHistogramCode {
   // Renderer load at fixed address success, fail, or not attempted.
@@ -149,6 +150,11 @@ static void RegisterLibraryPreloaderRendererHistogram(
   g_library_preloader_renderer_histogram_code_registered = true;
 }
 
+void SetNativeInitializationHook(
+    NativeInitializationHook native_initialization_hook) {
+  g_native_initialization_hook = native_initialization_hook;
+}
+
 void RecordLibraryLoaderRendererHistograms() {
   RecordChromiumAndroidLinkerRendererHistogram();
   RecordLibraryPreloaderRendereHistogram();
@@ -167,6 +173,9 @@ static void InitCommandLine(
 
 static jboolean LibraryLoaded(JNIEnv* env,
                               const JavaParamRef<jobject>& jcaller) {
+  if (g_native_initialization_hook && !g_native_initialization_hook()) {
+    return false;
+  }
   if (g_registration_callback == NULL) {

[Torne, 2017/01/03 12:13:50]

g_registration_callback already appears to be the exact mechanism you're adding
here, though the variable name doesn't match the "SetLibraryLoadedHook" function
used to set it. Could we just use this instead (and rename the variable to
g_library_loaded_hook)?

The content layer Init() function already does nothing other than call
SetLibraryLoadedHook. It seems like the current Init function chain is an
unnecessary level of indirection that we could just remove and replace with
this, as a minimum.

[Tobias Sargeant, 2017/01/04 00:24:53]

I started doing this, and removing the callback chain means touching a lot of
test code. Would you consider leaving it as a follow-up CL so that we can get
multiprocess fixed with this one?

I also can't coalesce the two hooks because currently the
g_registration_callback is used to run something after all native library
initialization is done, from a point where it can't just do it as the last
thing.

     return true;
   }