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

chrome/browser/android/chrome_entry_point.cc

 // 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.
 
 #include "base/android/jni_android.h"
+#include "base/android/library_loader/library_loader_hooks.h"
 #include "base/bind.h"
 #include "chrome/app/android/chrome_jni_onload.h"
 
 namespace {
 
 bool RegisterJNI(JNIEnv* env) {
   return true;
 }
 
 bool Init() {
   return true;
 }
 
+bool NativeInit() {
+  return android::OnJNIOnLoadInit(base::Bind(&Init));

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

This chaining mechanism looks weird and confusing every time I see it, and I
think we should get rid of it.

Instead of passing the chrome layer init function to content, which adds it to a
vector and passes it to base, which then calls them in reverse order, it would
make MUCH more sense if the chrome Init function just called the content init
function directly before it did its own work, and the content init function just
called the base one directly likewise.

The tree of component dependencies isn't dynamic, it's entirely known at
code-writing time :)

+}
+
 }  // namespace
 
 // This is called by the VM when the shared library is first loaded.
 JNI_EXPORT jint JNI_OnLoad(JavaVM* vm, void* reserved) {
-  if (!android::OnJNIOnLoadRegisterJNI(vm, base::Bind(&RegisterJNI)) ||
-      !android::OnJNIOnLoadInit(base::Bind(&Init))) {
+  if (!android::OnJNIOnLoadRegisterJNI(vm, base::Bind(&RegisterJNI))) {
     return -1;
   }
+  base::android::SetNativeInitializationHook(NativeInit);
   return JNI_VERSION_1_4;
 }