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

Issue 745586 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner:
Last visit > 30 days ago
Closed: May 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 3
Type: Task

Blocking:
issue 832560



Sign in to add a comment

Determine how to keep android.webkit and its support-library dupes on par

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

Issue description

We will dupe the classes in android.webkit into the WebView support library. We should make sure that these two packages are continuously on par.
 
Is it possible to extract all the public methods from the checked in Android SDK, and ensure that there are equivalent methods in the support library code?

I'm not certain whether it would be too onerous to have a build step that enforces this, but maybe it would be ok once we've initially reached parity.
Yepp, I think we should add that. Not sure what would be the best way of doing so :)
Depending on how/when we run that check it would break whenever we update the Android SDK.
(and we've added android.webkit methods since the last SDK build).
Blocking: -725019
Blocking: 832560
Cc: ntfschr@chromium.org
Note: our support lib and frameworks APIs sometimes intentionally deviate (e.g., SafeBrowsingResponseCompat has no public constructor). If we add this verification step, we need a whitelisting mechanism for such deviations.

Also, I don't know a nice way to do this automatically, because that would require landing new APIs simultaneously with support lib equivalents.
Status: WontFix (was: Assigned)
This bug is a remnant from the time when we wanted to generate the support library through code generation.

It feels like this problem should solve itself - if devs want a specific API they should ask for it, so if we miss implementing some API and nobody wants it anyway then we shouldn't bother? 

Sign in to add a comment