IssueTracker

Same here. I have links in a local html file referencing file:///android_res/drawable/ and on all gradle build flavors using another applicationId (added suffix) the Webview only shows broken links.

This behaviour seems not to be connected solely to Android 5.0 since it occurs on Android 4.4.4 too (tested with current cyanogenmod 11 build).

As a hotfix I added the following code to the gradle buildscript, which generates an additional R.java with changed java package for every flavor. I don't like this solution though.

android.applicationVariants.all{ variant ->
  variant.javaCompile.doFirst{
   copy {
        from "${buildDir}/generated/source/r/${variant.dirName}/com/example/application/R.java"
        into "${buildDir}/generated/source/r/${variant.dirName}/com/example/application/${variant.buildType.name}/"
    }
    File rFile = file("${buildDir}/generated/source/r/${variant.dirName}/com/example/application/${variant.buildType.name}/R.java")
    String content = rFile.getText('UTF-8')
    String newPackageName = "com.example.application.${variant.buildType.name}";
    content = content.replaceAll(/com.example.application/, newPackageName)
    rFile.write(content, 'UTF-8')
  }
}

I've recenly encountered this issue and I must say it's quite a nuisance. Searched half of the Internet just to find out that the problem lies in Gradle's applicationIdSuffix :). I think this bug should be reported to Android SDK Build Tools devs, because only they can do something about it.

IMHO it's the case of Android platform problem. Resources are packed, WebView tries to load them from wrong place. It's not build tools that put them in wrong place.

And by the way it's very frustrating bug.

[Comment deleted]

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

Android emulator version 25.3.0.0 (build_id 3705733)  right version

I see Avast antivirus running on the Task Manager screenshot. Could you please try disabling its realtime protection (or whatever it's called in it) and running the emulator without it? We've upgraded QEMU engine from 2.2 to 2.7 in the released version, and that may play bad with antivirus.
It's long shot, but as I'm out of ideas as of now I'd really love to give it a try.
Another option would be to change the AVD's CPU count to 1 and try it that way

Does the problem still exist with emulator 26.0.0?

Several users reported that comment #53 in https://code.google.com/p/android/issues/detail?id=250464 fixed their slowness issue

I have same problem
Win10 x64
i5 4670
ram 24gb
Nvidia 970

Android Studio 2.3
Emulator 26
Latest Android 7.1 x86 image
Latest HAXM with enabled virtualization

This issue happened about 3 weeks ago.
What i tried:
- disabled Avast
- Roll back to AS 2.2
- upgrade to AS 2.4 alpha
- tried all Windows update manipulations (such uninstalling, upgrading latest KB patches)
- tested host OS with benchmarks to be sure it is not an OS performance issue
- tried -no-audio param for Emulator

all without success

here is top results:
  PID PR CPU% S  #THR     VSS     RSS PCY UID      Name
 1636  1  22% S    87 1179000K 104232K  fg system   system_server
 2406  1  16% S    65 1333040K 114996K  fg u0_a7    com.google.android.gms
 2000  1  13% D    48 1164636K  86964K  fg u0_a7    com.google.android.gms.persistent
 2767  1   5% S    19 1134632K  62852K  fg u0_a7    com.google.android.gms.unstable
 1242  0   3% S     1      0K      0K  fg root     kworker/0:1H
    4  0   2% S     1      0K      0K  fg root     kworker/0:0
 1358  1   2% S    12 138352K  12052K  fg media    /system/bin/mediaserver
 2077  1   2% S    14 998800K  37376K  bg u0_a2    android.process.acore
 2018  1   2% S    30 1022312K  46920K  fg radio    com.android.phone
 1349  0   1% S     1      0K      0K  fg root     kworker/0:2

and when trying to scroll Launcher:

 PID PR CPU% S  #THR     VSS     RSS PCY UID      Name
 2025  1  24% S    18 1037796K  58136K  fg u0_a64   com.android.launcher3
 1267  1  23% S    13  55612K   3916K  fg system   /system/bin/surfaceflinger
 1636  1  15% S    84 1147580K  97280K  fg system   system_server
 1349  0   2% S     1      0K      0K  fg root     kworker/0:2
 1272  1   1% S     6  10800K    688K  fg root     /sbin/adbd
 1780  0   1% S    25 1037560K  66900K  fg u0_a13   com.android.systemui
   12  1   0% S     1      0K      0K  fg root     ksoftirqd/1
 4023  0   0% R     1   4236K   1108K  fg root     top
   13  1   0% S     1      0K      0K  fg root     kworker/1:0
    8  1   0% S     1      0K      0K  fg root     rcu_preempt

as you can see there is unusual high cpu activity which i didn't observe early.

here is simple list scroll result:
http://i.imgur.com/ykR853B.png

usually these bars don't exceed the navbar height

windows qemu-system-i386.exe process eats ~15% in idle and 65-70% when scrolling/flinging any app inside the emulator. which is unusual too.

if you need additional degug info - let me know

I've just found the reason of lags. Avast antivirus. To resolve issue you should UNINSTALL it. Just disabling is not enough. Spent few weeks to realize this :)

Thank you so much for the update!

We'll keep researching to understand how to speed up our emulator when running with Avast; what we know is that avast hooks into the APIs QEMU uses to read and write disk images, and this slows it down by 10-100x. For now I'm closing this bug with a workaround you found (disable Avast) as a fix. I'll create another bug to make it clear it's about Avast coexistence

Bug about Avast specifically: http://b.android.com/360446