Webview seems to use applicationId instead of packagename for R class [37026699]

Fixed

Bug

Status Update

No update yet.

Description

re...@gmail.com

created issue #1

Feb 22, 2015 02:16PM

I am not completely sure if this is indeed the issue but on Android 5.0 when I try to load a HTML file from res/raw using the scheme file:///android_res/raw/index.html I get a ClassDefNotFoundException when my applicationId differs from my package name.

I have a applicationId and packageName org.myorg.myapp and use an applicationIdSuffix '.debug' for debug builds. The classloader is then looking for the class org.myorg.myapp.debug.R.raw, which does not exist because my R class is org.myorg.myapp.R.

The correct behaviour should be that the class {packagename}.R should be loaded instead of {applicationId}.R

I get this error on a Motorola XT1092 running android 5.0

Comments

aa...@hotmail.com <aa...@hotmail.com> #2Feb 26, 2015 11:02AM

Attached reproducing video of an app using calculateWindowSizeClass and LocalConfiguration:

On the second time resizing to be 50%/50% from smaller, the displayed configuration is incorrect.

aa...@hotmail.com <aa...@hotmail.com> #3Feb 27, 2015 01:41PM

When resizing the activity in multi-window mode under those conditions, there are cases where:

the Activity is not recreated Activity.onConfigurationChanged is not called View.onConfigurationChanged is not called

Is this just for 33 / is there a framework bug filed? The amount of broken things in configuration land we already had to workaround in Compose is a bit untenable. It seems like we are missing a lot of test coverage in the platform to avoid these issues hitting us in the future

ma...@gmail.com <ma...@gmail.com> #4Sep 28, 2015 01:50PM

In any case this seems like more ammunition for us to push more strongly on 'pure-compose apps should always opt out of configuration changes'

[Deleted User] <[Deleted User]> #5Nov 30, 2015 07:10AM

Yes, API 33 introduced this behavior, (internal) platform bug is here: b/247013643

am...@google.com <am...@google.com> #6Dec 1, 2015 02:31AM

Assigned to am...@google.com.

I was incorrect, this is also reproducible on API 32 as well. Not reproducible on API 31.

am...@google.com <am...@google.com> #7Dec 7, 2015 10:07AM

Status: New

Adam/Louis, how do we want to handle this one? Is there someone on platform who should take this, or since API 32 is already out in the wild maybe this should go to devrel to push more strongly on 'pure-compose apps should always opt out of configuration changes'.

to...@google.com <to...@google.com> #8Mar 22, 2016 11:01AM

deleted

re...@gmail.com <re...@gmail.com> #9Mar 24, 2016 09:54AM

I'm having issues on pre-33 api levels on a pure compose app (has all configChanges added in the manifest file) pared with AppCompatActivity just for multi language support. When changing the language I'm using AppCompatDelegate.setApplicationLocales(compat) which calls onConfigurationChanged on the activity. LocalConfiguration changes to the new configuration on 33+ but remains the same on pre-33. Workaround that i've found is calling if (Build.VERSION.SDK_INT < 33) contentView.dispatchConfigurationChanged(newConfig) in onConfigurationChanged. I'm guessing it's a compose issue since activity wise everything works as expected.

re...@gmail.com <re...@gmail.com> #10Mar 24, 2016 10:01AM

#comment9 sounds like b/321896385, which is also related to LocalConfiguration but a separate issue.

to...@google.com <to...@google.com> #11Mar 29, 2016 07:59PM

Thanks for the heads up, I've tried to find a related issue but only managed to find this one after a brief search.

to...@google.com <to...@google.com> #12Apr 1, 2016 02:25PM

to...@google.com <to...@google.com> #13Apr 1, 2016 02:34PM

Thanks for the heads up, I've tried to find a related issue but only managed to find this one after a brief search.

[Deleted User] <[Deleted User]> #14Apr 1, 2016 02:40PM

#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?

to...@google.com <to...@google.com> #15Apr 1, 2016 02:53PM

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

to...@google.com <to...@google.com> #16Jun 22, 2016 01:09PM

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 :/

re...@gmail.com <re...@gmail.com> #17Jun 22, 2016 04:43PM

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

to...@google.com <to...@google.com> #18Jun 22, 2016 04:45PM

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 :)

re...@gmail.com <re...@gmail.com> #19Jun 22, 2016 05:21PM

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 :)

de...@tangible.tech <de...@tangible.tech> #20Mar 11, 2017 07:05PM

[Comment deleted]

je...@gmail.com <je...@gmail.com> #21Feb 28, 2018 08:40AM

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

to...@google.com <to...@google.com> #22Feb 28, 2018 09:29PM

Marked as fixed, reassigned to to...@google.com.

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)

[Deleted User] <[Deleted User]> #23Mar 24, 2019 10:49AM

https://issuetracker.google.com/issues/128345287

ah...@gmail.com <ah...@gmail.com> #24Oct 29, 2023 02:06PM

طوفان

ah...@gmail.com <ah...@gmail.com> #25Oct 29, 2023 02:06PM