Remove app context init from LibraryLoader.

content/public/android/java/src/org/chromium/content/app/ChildProcessServiceImpl.java

 // Copyright 2016 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.content.app;
 
 import android.content.Context;
 import android.content.Intent;
 import android.graphics.SurfaceTexture;
 import android.os.Binder;
@@ skipping 163 matching lines @@
                         }
                     }
                     boolean isLoaded = false;
                     if (CommandLine.getInstance().hasSwitch(
                             BaseSwitches.RENDERER_WAIT_FOR_JAVA_DEBUGGER)) {
                         android.os.Debug.waitForDebugger();
                     }
 
                     boolean loadAtFixedAddressFailed = false;
                     try {
-                        LibraryLoader.get(mLibraryProcessType).loadNow(hostBrowserContext);

[Ted C, 2016/09/21 18:36:51]

this seems like it is changing the behavior.  previously, it was using the
context of the browser process, now it looks like it will be using the context
of the process.  I don't know this class well enough to say what is correct, but
I think this need a bit more digging.

Change made here:
https://codereview.chromium.org/2049843004/diff/420001/content/public/android...

And looking at the code, we always pass the app context for both when creating
the browser renderer process, so I think this name is actually quite misleading.
 Maybe for web_apk this is indeed something else, but we should fix the naming
here as it doesn't seem like this would be the browser context but instead the
application context for the renderer isolated process (maybe we should just drop
Browser from the name, and clarify that the host context can match context if
need be).

[Xi Han, 2016/09/21 18:52:27]

Thank you Ted for sending this CL to me!

The |hostBrowserContext| is needed here. This is because WebAPK can also host
renderer process, and the way to create a child process is to use reflection to
create a ChildProcessServiceImpl which loads Chrome's native code. Depending in
which app this code is actually running, the |hostBrowserContext| is always
passed in when the ChildProcessServiceImpl was created, since it doesn't always
equal to the context of the current app.

To WebAPK, "host browser" means the browser that owns the WebAPK. Currently it
means Chroms only, but could be beta/dev/canary/stable. I don't have a better
name in my mind, any suggestion?

[Ted C, 2016/09/21 19:04:18]

What process do webappks generate their renderers in?  Assuming I'm reading
this code correct, this is how we initialize our renderers/gpu processes
etc, right?  And that doesn't happen in the browser process but in the
respective
processes (sandboxed for renderers, not for gpu).

That is why the naming is weird to me.  For Chrome (in regular mode), the
context
used is fully owned/lifetime bound to the renderer process.  The fact that
we are including the word "browser" to me implies that we are using the browser
context to load the native library and that is not the case for chrome.

I think just dropping the name "browser" from the param name is fine.  Or maybe
libraryLoadingContext to be more of a description of its usage instead of
describing
where it came from.

[Xi Han, 2016/09/21 19:37:24]

In WebAPK's AndroidManifest.xml, we declares WebApkSandboxedProcessService, and
when this service is created by Android, it loads ChildProcessServiceImpl to
create renderers. So I think renderers are generated in the default process that
the WebAPK is created, please correct me if I am wrong.

I am fine with removing "browser" and using "hostContext" or something like
that. We definitely should avoid the confusing that "browser" could indicate the
"browser process".

[Peter Wen, 2016/09/26 19:02:01]

Opps, didn't mean to make this change in behaviour. Renamed to hostContext and
discussing offline with Xi came to the conclusion that this is necessary because
WebAPK wants its own application context to be stored in ContextUtils but wants
to just load the library in LibraryLoader with Chrome's application context.

+                        LibraryLoader.get(mLibraryProcessType).loadNow();
                         isLoaded = true;
                     } catch (ProcessInitException e) {
                         if (requestedSharedRelro) {
                             Log.w(TAG, "Failed to load native library with shared RELRO, "
                                     + "retrying without");
                             loadAtFixedAddressFailed = true;
                         } else {
                             Log.e(TAG, "Failed to load native library", e);
                         }
                     }
                     if (!isLoaded && requestedSharedRelro) {
                         linker.disableSharedRelros();
                         try {
-                            LibraryLoader.get(mLibraryProcessType).loadNow(hostBrowserContext);
+                            LibraryLoader.get(mLibraryProcessType).loadNow();
                             isLoaded = true;
                         } catch (ProcessInitException e) {
                             Log.e(TAG, "Failed to load native library on retry", e);
                         }
                     }
                     if (!isLoaded) {
                         System.exit(-1);
                     }
                     LibraryLoader.get(mLibraryProcessType)
                             .registerRendererProcessHistogram(requestedSharedRelro,
@@ skipping 242 matching lines @@
     private static native void nativeInitChildProcessImpl(
             ChildProcessServiceImpl serviceImpl, int cpuCount, long cpuFeatures);
 
     /**
      * Force the child process to exit.
      */
     private static native void nativeExitChildProcess();
 
     private native void nativeShutdownMainThread();
 }