Remove app context init from LibraryLoader.

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

Index: content/public/android/java/src/org/chromium/content/app/ChildProcessServiceImpl.java
diff --git a/content/public/android/java/src/org/chromium/content/app/ChildProcessServiceImpl.java b/content/public/android/java/src/org/chromium/content/app/ChildProcessServiceImpl.java
index 9bf884aacb964ac2d13909bea8318d3136412df4..e6a53cff4a631a27e02e276f7bb2789f82ff52ca 100644
--- a/content/public/android/java/src/org/chromium/content/app/ChildProcessServiceImpl.java
+++ b/content/public/android/java/src/org/chromium/content/app/ChildProcessServiceImpl.java
@@ -181,7 +181,7 @@ public class ChildProcessServiceImpl {
 
                     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) {
@@ -195,7 +195,7 @@ public class ChildProcessServiceImpl {
                     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);