Android webview tries to switch to CE context

android_webview/glue/java/src/com/android/webview/chromium/WebViewChromium.java

Index: android_webview/glue/java/src/com/android/webview/chromium/WebViewChromium.java
diff --git a/android_webview/glue/java/src/com/android/webview/chromium/WebViewChromium.java b/android_webview/glue/java/src/com/android/webview/chromium/WebViewChromium.java
index 4a3892673442c2b9ec08979ddb21ba8d4649b45a..dad70a816c5e41bb43789b1d776b1e5e90f360c6 100644
--- a/android_webview/glue/java/src/com/android/webview/chromium/WebViewChromium.java
+++ b/android_webview/glue/java/src/com/android/webview/chromium/WebViewChromium.java
@@ -114,15 +114,16 @@ class WebViewChromium implements WebViewProvider, WebViewProvider.ScrollDelegate
     // init is ofter called right after and is NOT threadsafe.
     public WebViewChromium(WebViewChromiumFactoryProvider factory, WebView webView,
             WebView.PrivateAccess webViewPrivate, boolean shouldDisableThreadChecking) {
-        WebViewChromiumFactoryProvider.checkStorageIsNotDeviceProtected(webView.getContext());
+        Context ctx = WebViewChromiumFactoryProvider.switchToCredentialProtectedStorage(

[Torne, 2016/09/21 12:04:18]

You're still allowing a WebView to be constructed with a device-protected
context. We don't want this to be permitted. This file should just be left
as-is.

[Nate Fischer, 2016/09/22 04:21:12]

I'm a bit confused about what you mean here.

Digging through the code, it seems like
WebViewChromiumFactoryProvider.initialize() is being called before this point is
ever reached. I believe WebViewChromiumFactoryProvider.initialize() successfully
validates that it is given a CE context (or at least it will once I fix the
concerns raised for that file).

So I agree that I should revert this diff, since the check does appear to be
redundant. However, I don't see how a DE context could still slip through, since
the check happens even earlier than this point.

Please correct me if I'm mistaken and I'm overlooking an entry point for
creating WebViews.

[Torne, 2016/09/22 09:59:54]

These are two totally unrelated things that use different contexts. The very
first time a process calls any function relating to the webview implementation,
we go through WebViewChromiumFactoryProvider.initialize(), which does *not*
receive any context whatsoever, and therefore has to retrieve one for itself by
using a @SystemApi framework method that gives us the Application object for the
application in this process. In all normal apps, the Application object is a CE
context, but in system apps that default to DE, the Application is also DE,
which is the problem we're trying to work around. This code is only called once
in the entire lifetime of the process, and happens even if the app does
something unrelated to constructing an instance of WebView, such as interacting
with CookieManager via its global singleton.

WebViewChromium's constructor here is called when the app actually does "new
WebView(context)" and so at this point we have the specific context provided to
us by the application for the current activity. We want to make sure that this
context is always a CE context, in all apps, no matter whether they default to
DE or not, and the current code already does that correctly - you shouldn't
remove the check, it's not redundant.

+                webView.getContext());
         mWebView = webView;
         mWebViewPrivate = webViewPrivate;
         mHitTestResult = new WebView.HitTestResult();
-        mContext = ResourcesContextWrapperFactory.get(mWebView.getContext());
+        mContext = ResourcesContextWrapperFactory.get(ctx);
         mAppTargetSdkVersion = mContext.getApplicationInfo().targetSdkVersion;
         mFactory = factory;
         mShouldDisableThreadChecking = shouldDisableThreadChecking;
-        factory.getWebViewDelegate().addWebViewAssetPath(mWebView.getContext());
+        factory.getWebViewDelegate().addWebViewAssetPath(ctx);
     }
 
     static void completeWindowCreation(WebView parent, WebView child) {