[Cronet] Make sure to only pass the application Context to InitApplicationContext to avoid DCHECK fa

components/cronet/android/java/src/org/chromium/net/CronetUrlRequestContext.java

Index: components/cronet/android/java/src/org/chromium/net/CronetUrlRequestContext.java
diff --git a/components/cronet/android/java/src/org/chromium/net/CronetUrlRequestContext.java b/components/cronet/android/java/src/org/chromium/net/CronetUrlRequestContext.java
index 03f4944adeeb3592f79e853f183ee8ae89f871e5..9ebfa1d946af92eec360452e24d9be37d2d44491 100644
--- a/components/cronet/android/java/src/org/chromium/net/CronetUrlRequestContext.java
+++ b/components/cronet/android/java/src/org/chromium/net/CronetUrlRequestContext.java
@@ -44,7 +44,7 @@ public class CronetUrlRequestContext extends UrlRequestContext  {
         CronetLibraryLoader.ensureInitialized(context, config);

[mmenke, 2015/03/06 15:58:28]

Should this also use getApplicationContext?  Also, I think we should be clearer
on what is the app context and what is the...erm...non-app context.  Looking
through the files, I have no idea when we expect to have an app context, and
when any old context will do.

[pauljensen, 2015/03/06 16:21:15]

I tried to explain this in the CL description.  I think the best practice is to
use whatever Context a caller passed in whenever possible as this one contains
the most wrappers which may be adding functionality.  An application context
should only be used when necessary.

InitApplicationContext is AFAIK the only thing that needs an application
Context.  I imagine InitApplicationContext only really needs an application
Context instead of a normal Context because it makes sure the Context pointer it
receives isn't changing (which is the case for an application Context only).
I don't believe ensureInitiailized() requires an application Context, so I'd
recommend just passing |context| straight in.
I tried in this CL to rename all parameters accordingly:  "context" when any old
Context will do.  "appContext" or "app_context" when only an application Context
will do.  Unfortunately AFAIK there isn't a way to enforce this with types.

[mmenke, 2015/03/06 16:52:23]

Hrm...For some reason I was thinking you were adding more
getApplicationContext() than you are...  Looks like you're doing as well as can
be expected here, given the rather funky nature of the whole app context vs
context divide.

         nativeSetMinLogLevel(getLoggingLevel());
         mUrlRequestContextAdapter = nativeCreateRequestContextAdapter(
-                context, config.toString());
+                context.getApplicationContext(), config.toString());
         if (mUrlRequestContextAdapter == 0) {
             throw new NullPointerException("Context Adapter creation failed.");
         }
@@ -195,8 +195,7 @@ public class CronetUrlRequestContext extends UrlRequestContext  {
     }
 
     // Native methods are implemented in cronet_url_request_context.cc.
-    private static native long nativeCreateRequestContextAdapter(
-            Context context, String config);
+    private static native long nativeCreateRequestContextAdapter(Context appContext, String config);

[mef, 2015/03/06 16:55:55]

does this really need appContext? It doesn't seem to use it.

 
     private static native int nativeSetMinLogLevel(int loggingLevel);