Use of file:///android_res/drawable/ url works under eclipse but not in production

Question

I have a problem that is driving me nuts. I have a static html file (assets/help/index.html) that needs to include some images. As I want different images for different densities and the images are already included in drawable-{ldpi,mdpi,hdpi} I thought I'd use the following html code:

<img src="file:///android_res/drawable/image.png">

This works excellent under eclipse! Unfortunately in the production version (build with the maven android plugin) the webview that displays the html page shows broken image icons.

I have tried opening the page using loadUrl and loadDataWithBaseUrl (first reading the file myself), the latter with a base url of file:///android_res/drawable. Both attempts succeed under eclipse but fail in the maven version.

So I unpacked both the Eclipse generated apk and the maven generated one and did a diff -r between the two because there must clearly be a difference.

I'm baffled to find only a few trivial differences (mostly signing differences as the eclipse apk is signed with the debug certificate and the maven one with my official certificate). Apart from that, the content of the apks are identical!

Does anyone have any idea what is going on or how to proceed in uncovering more information?

Answer 1

I had a similar issue using proguard and I found an explanation (and the a solution!) here.

In my case proguard obfuscated R class and android_res/[...] couldn't be found anymore.

I solved adding a rule to proguard.cfg:

-keepclassmembers class **.R$* {
    public static <fields>;
}

-keep class **.R$*

I don't know about maven but hope this helps.

Answer 2

There are reasons for using file:///android_res instead of file:///android_asset. One of them is that Android library projects cannot have assets.

If you happen to want to access resources which are defined in a library project from a WebView and rename the package name using the respective option of the android-maven-plugin (which in turn relies on some Android SDK feature) then you hit a rather weird bug.

Android does this in the android.webkit.BrowserFrame::inputStreamForAndroidResource (at least in 4.1.2):

final Class<?> d = mContext.getApplicationContext().getClassLoader().loadClass(
mContext.getPackageName() + ".R$" + subClassName);

This is a dynamic lookup of the R class and it uses the application's package name as a Java package name. However this does not work because the R class in the renamed package name will not exist.

A possible workaround is the following: During your release build, dynamically make a copy of your real R class and place it into the Java package that fits the renamed application package name. Make sure to update the ''package'' statement in the copied source as well.