IssueTracker

[Comment deleted]

The applicationIdSuffix/packageName/etc seem to be a Gradle-specific concept that applies only at build time.

At runtime, the only way WebView has to identify your app is the actual package name of the APK, and that will be the full string with the suffix included. The package that was used at compile time when generating the R class is not stored in the APK, and there's not really any way for WebView to know what it was as far as I know.

[Comment deleted]

Isn't the package name attribute in the root node of the AndroidManifest preserved when an app is packaged? That would be the correct package to use when loading the R class

I don't think so. You could check what's actually in your packaged APK with "aapt dump xmltree <apkfilename> AndroidManifest.xml" - if it's not there, then WebView can't get to it at runtime either.

I haven't actually checked this as I don't have an android studio project handy currently (will try soon) but I suspect that Gradle passes the app name with the suffix appended to aapt with --package-name, which causes aapt to replace the name specified in your manifest with the one on the command line. The original name doesn't end up in the APK at all.

OK, I tried this out in Gradle to check what the terms that it uses really correspond to when building a package, and also read the docs at http://tools.android.com/tech-docs/new-build-system/applicationid-vs-packagename

This has confirmed what I wrote in my previous comments, unfortunately. What Gradle calls the package name (the name of the package that your Java sources and R class are stored in) is *not* the APK's actual package name that gets set at build time, and is *not* stored anywhere at all or accessible at runtime whatsoever. The APK is solely identified by the application ID with the suffix added, and the original package name is overwritten in the manifest. Android itself does not have this concept of the package name and application ID being separate; it's just a build-time trick Gradle is doing for you.

So, unfortunately, it doesn't look like there is any way for WebView to reliably know where your R class is. We might be able to add an API for the app to specify this in a future version (though I'm not entirely sure how that would actually work; it'd probably have to be a static method on WebView?), but that won't help you for existing OS versions, we can't add new APIs retroactively.

I think your only short-term options are to not use applicationIdSuffix or to not use file:///android_res/ in WebView. You could instead use a different URL (one that isn't handled by WebView itself), intercept it with shouldInterceptRequest, and provide the data by reading it from your resources yourself. I understand that that's not very convenient, but it seems like the only actual option here that works right now.

One thing WebView could do which would work in *some* cases is to just try to strip off components from the package name if the R class isn't found, going up one package at a time until we find it. That would work if you've just added a suffix like ".debug" - we'd fail to find com.example.debug.R and then try com.example.R instead. That still wouldn't work for any case where the package name is totally different, though (which gradle permits you to do). I'll look into whether this is safe to do and if so we could maybe add this in a future webview update, but it still won't fix the problem for users of pre-Lollipop Android versions (who don't get WebView updates), or for users who just don't have the latest webview update installed, so you're going to have to work around this problem in your app anyway to continue supporting those devices. :/

I've filed http://crbug.com/599869 to track potentially handling the suffix case in the WebView code, but note that as I said, this will only fix it for users with the latest WebView on Android 5.0+ devices, and so you will need to still work around this in your application if you want it to work on any other devices.

#11 thanks for explanation

I think the whole scheme file:///android_res/ ideally should be deprecated in favor to android.content.ContentResolver.SCHEME_ANDROID_RESOURCE, which allows specify package and resId and used everywhere in Android except WebView.

http://androidbook.blogspot.ru/2009/08/referring-to-android-resources-using.html

http://stackoverflow.com/a/4855376/1430070

What do you think?

Perhaps, but again, we can't add that for existing users without updatable WebView versions, so even if we did add it, it wouldn't really solve the problem for your apps since ~2/3 of the android device population doesn't get webview updates yet: http://developer.android.com/about/dashboards/index.html

WebView 53 and onward will attempt to strip package name components from the app package name until it finds an R class, which will deal with the simplest cases here (applicationIdSuffix appending a suffix to the base name), but not other cases where the package name is unrelated to the R class name.

This won't fix it for users with pre-L android versions, or who don't upgrade to at least WebView 53 once it's released, though, so you will not be able to rely on this as a full workaround :/

Awesome! That updatable webview is one of the best thing you guys have done is the last couple of years!

Well, this doesn't really solve your actual problem (for years yet), as I said, since there's still a significant population of pre-L devices that you probably want to keep supporting, and not all L+ devices will ever get upgraded to a sufficiently recent WebView, but yes, the fact that we can do this at all is useful :)

Well I my problem was with dev build, and I do most of the development on
L+ devices so, it might not solve the real issue, but it is sufficient for
me :)

[Comment deleted]

The fix that had been applied is not working anymore.

There's regression caused by https://chromium.googlesource.com/chromium/src.git/+/95d6e720c235f105aa3182e2a1b2f826cfaa483f%5E%21/#F1
I've left a comment on https://bugs.chromium.org/p/chromium/issues/detail?id=599869#c12

I'm fixing this upstream on https://crbug.com/599869.

I'm going to close this bug as we aren't planning to do anything further to address this issue beyond the change made some time ago in #16 (and fixing it again after it broke in a more recent version)