New issue
Advanced search Search tips

Issue 746972 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner: ----
Closed: Dec 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 3
Type: Bug

Blocking:
issue 725019



Sign in to add a comment

How to deal with android.webkit utility classes?

Project Member Reported by gsennton@chromium.org, Jul 20 2017

Issue description

With the WebView Support Library we want to provide as much functionality as possible from the WebView APK to app developers. We will dupe many of the android.webkit classes to avoid depending on a certain Android version - but there are some classes, especially utility classes like DateSorter and URLUtil, that are not related to the WebView APK.

The question is: should we dupe these as well, or just leave them be?
It seems error-prone / unnecessary to dupe them if they can be self-contained in the Android platform anyway.
On the other hand if we don't dupe these classes users will be stuck with their platform version of them - though we probably shouldn't see implementation changes to these classes anytime soon anyway?

(Torne, I think you touched on this briefly somewhere, I just can't remember when/where ;)).
 

Comment 1 by torne@chromium.org, Jul 20 2017

I think the best thing to do is leave them alone and have app developers still include them from android.webkit. I don't think they are used that frequently, and I don't think they have changed much in a long time - we should probably validate both of those.
How do we validate how frequently they are used, through Marmot?
And yeah, we should probably just ensure that those APIs haven't changed since KitKat.

Comment 4 by sgu...@chromium.org, Aug 30 2017

yeah Marmot. If you can pass me a list of classes, I can check them out.
Status: WontFix (was: Available)
None of the utility classes have any new APIs since L, I'm marking this as won't fix.

Sign in to add a comment