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

chrome/browser/android/chrome_entry_point.cc

Index: chrome/browser/android/chrome_entry_point.cc
diff --git a/chrome/browser/android/chrome_entry_point.cc b/chrome/browser/android/chrome_entry_point.cc
index 789b99b46a35d9abc9570817ce9b61ce56d653f6..5bc9215ded3a07c1f0967cfd1f5461d7ffd50081 100644
--- a/chrome/browser/android/chrome_entry_point.cc
+++ b/chrome/browser/android/chrome_entry_point.cc
@@ -3,6 +3,7 @@
 // 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"
 
@@ -16,13 +17,17 @@ 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;
 }