New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 808417 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Last visit > 30 days ago
Closed: Feb 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 1
Type: Bug

Blocking:
issue 781754



Sign in to add a comment

Turn WebViewChromiumFactoryProvider into a singleton

Project Member Reported by gsennton@chromium.org, Feb 2 2018

Issue description

The WebView Support Library glue will need to hook into the existing WebViewChromiumFactoryProvider created when the framework loads code from the WebView APK. At the moment that provider is owned by android.webkit framework code - so there's no straight-forward way to pass that object to the support library code without exposing an addition Android API (that wouldn't make sense to apps).

We will turn WebViewChromiumFactoryProvider into a singleton to allow the support library to access it.
 
Cc: boliu@chromium.org torne@chromium.org
And in L we don't call WebViewChromiumFactoryProvider, we call its ctor, so the class that will have to be a singleton is not the WebViewChromiumFactoryProvider itself, but something it owns (like WebViewChromiumAwInit added in
https://chromium-review.googlesource.com/c/chromium/src/+/895942

I'll have to scope out exactly what the support library glue needs access to before deciding which class to turn into a singleton (if we want access to existing glue-layer adapters we might want another class to hold those rather than WebViewChromiumAwInit..).

Comment 2 by boliu@chromium.org, Feb 2 2018

> And in L we don't call WebViewChromiumFactoryProvider.create, we call its ctor

In practice, there's still only one instance of WebViewChromiumFactoryProvider even though you can create more. So you could say have the constructor set a global variable, and have a getInstance method that returns that.

Comment 3 by boliu@chromium.org, Feb 2 2018

although that only works if support lib can force android to create WebViewChromiumFactoryProvider first before trying to use it
Android will always create WebViewChromiumFactoryProvider first - the way the support library hooks into the webview apk classloader will trigger the code in the framework (WebViewFactory) that reflects into WebViewChromiumFactoryProvider.
Project Member

Comment 5 by bugdroid1@chromium.org, Feb 6 2018

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/3854eccb09e28bb9316aa1305ad96aa6f8c8b199

commit 3854eccb09e28bb9316aa1305ad96aa6f8c8b199
Author: Gustav Sennton <gsennton@google.com>
Date: Tue Feb 06 02:13:59 2018

Add a singleton from where to fetch the WebViewChromiumFactoryProvider.

The WebView support library glue needs a way to fetch the
WebViewChromiumFactoryProvider, this CL adds a mechanism for keeping
track of our only instance of WebViewChromiumFactoryProvider.

Bug:  808417 

Change-Id: I37c76d82b01004753d962ade6874184b28eaa54b
Reviewed-on: https://chromium-review.googlesource.com/901624
Commit-Queue: Gustav Sennton <gsennton@chromium.org>
Reviewed-by: Richard Coles <torne@chromium.org>
Reviewed-by: Bo <boliu@chromium.org>
Cr-Commit-Position: refs/heads/master@{#534588}
[modify] https://crrev.com/3854eccb09e28bb9316aa1305ad96aa6f8c8b199/android_webview/glue/java/src/com/android/webview/chromium/WebViewChromiumFactoryProvider.java

Status: Fixed (was: Assigned)

Comment 7 by boliu@chromium.org, Feb 6 2018

oh one more note for support lib, you probably want @UsedByReflection on things that will be used by reflection, so proguard doesn't obfuscate or optimize away the things you need
Ah, thanks Bo! Filed  crbug.com/809471 

Sign in to add a comment