New issue
Advanced search Search tips

Issue 783398 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner: ----
Closed: Apr 2018
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 3
Type: Bug

Blocking:
issue 725019



Sign in to add a comment

Should we allow changes to the package name of the WebView Support Library?

Project Member Reported by gsennton@chromium.org, Nov 9 2017

Issue description

Because of the way we will make calls between the WebView Support Library, and the WebView Glue layer (essentially through class+methodname lookups), if we rename the package, or any of the classes in the interfaces for communication between the support library, and the webview glue layer, we will break that communication in older WebView versions.

Should we have some mechanism to allow for package name changes? (like sending the package name of the support library interfaces to the webview apk on initialization).

Relying on not making changes to an interface like this (ever) seems brittle, I wonder if I'm missing something even more restricting (that the package name) that we can't change after creating the dependency between the support library and the webview apk..
 
The current plan for this is to include a proguard-rule to ensure apps don't rename the boundary-interface package (and its classes/methods) in the support library.
Status: Fixed (was: Available)
We've added a proguard-rule to the support library to avoid obfuscating boundary interface names.

Sign in to add a comment