Why start using -libraryjars when I never needed it before?

Question

Since I updated ADT from 16 to 18 (which mandated Proguard update from 4.6 to 4.8), Proguard has been acting very weirdly (and inconsistently?).

The latest such probl

Answer 1

First, investigate what Proguard is telling you:

Warning: com.bta.LibProj2: can't find referenced class com.bta.R$string
Warning: com.bta.MyDlg1: can't find referenced class com.bta.R$string

It can't find com.bta.R$string. Why not? Is com.bta.R$string there? Not the source code, we don't care about source at this point. Is the .class file there? If it's in the filesystem, is it actually referenced in the Proguard configuration file? Make sure you know how it's supposed to get included; what's referencing com.bta.R$string? You're probably going to be using javap to figure that out.

A better sledgehammer to use in this case isn't to turn off warnings (since they're actually warning you about something important), it's to tell Proguard to keep the com.bta classes that are missing, something like this:

-keep class com.bta.**

The recommendation to think about library jars is just a recommendation. It's apparently a common misconfiguration of proguard, so adding a note to point people in that direction is perfectly reasonable. It didn't solve your problem, but that doesn't mean it's not useful advice.

BTW, I did try to add the libraries I have been using by specifying all of them in -libraryjars lines, but Proguard's behavior only got worse: It would fail without giving any of the error log that I quoted above.

You probably need those -libraryjars entries. They don't make the problem worse. You've gone from a configuration that has N things wrong (not specifying -libraryjars) to a configuration that has N - 1 things wrong. Fix the N - 1 solution. What errors does it give, if any? If there are no errors, what happens if you turn warnings back on?

Experts only: you can in fact have a useful configuration without the -libraryjars entries, but you'll need a complete understanding of exactly what Proguard is doing with your code. And off the top of my head, I can't think of any reason other than performance for why you would want to do this.

Answer 2

I had similar issues after the latest update of SDK and ADT, eventually requiring me to checkout my project from scratch. Try checking out a new copy of your project, see if that works.

Answer 3

Problem solved. After much search for clues here in SO, I finally found this hint by no other than Proguard's developer himself:

-dontwarn scala.**

I'm not using anything that contains "scala" and I don't know what scala is. But that gave me the idea of placing a -dontwarn on my own application package:

-dontwarn com.bta.**

That did the trick.

For the record, the search phrase that led me to finding this hint was: proguard admob "can't find referenced class".

P.S. Proguard's suggestion You may need to specify additional library jars (using '-libraryjars') wasn't even in the right direction...

UPDATE: While -dontwarn com.bta.** allowed producing a signed APK, it crashed as soon as I tried to launch it with:

ClassNotFoundException: com.bta.myapp.MyAppActivity in loader dalvik.system.PathClassLoader[/data/app/com.bta.myapp.myapp-1.apk]. 

What a nightmare.

UPDATE 2: -dontwarn com.bta.** turned out to be way too inclusive. I changed it to:

-dontwarn com.bta.myapp.MyAppActivity.R**

And now everything runs well without incident. What a nightmare.

After wasting way too much time on debugging the very tools that are supposed to save me time, I discovered the source of the problem. It's a bug in the Android SDK tools. It is documented as have been solved in r17, but I am using the latest of today (June 18 2012) and it hasn't been solved! (see comment 24). Comment 25 also describes the workaround that allows me now to proceed with my actual development.

Bugs are fact of life in complex systems. But the fact that neither Proguard nor the build tools that feed input to Proguard could provide any helpful error message (in fact they did exactly the opposite), suggests something is broken in the "methodology" of the Android development tools recommended by Google.