Determine how to keep android.webkit and its support-library dupes on par |
|||||
Issue descriptionWe will dupe the classes in android.webkit into the WebView support library. We should make sure that these two packages are continuously on par.
,
Jul 20 2017
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.
,
Jul 20 2017
(and we've added android.webkit methods since the last SDK build).
,
Apr 13 2018
,
Apr 13 2018
,
May 11 2018
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.
,
May 11 2018
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 |
|||||
Comment 1 by tobiasjs@chromium.org
, Jul 18 2017