Best adt questions in June 2012

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

9 votes

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 problem is when I try to export a signed (release) APK, I receive the following errors:

Proguard returned with error code 1. See console
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
Warning: com.bta.MyMenu: can't find referenced class com.bta.R$menu
Warning: com.bta.R: can't find referenced class com.bta.R$attr
Warning: com.bta.R: can't find referenced class com.bta.R$drawable
Warning: com.bta.R: can't find referenced class com.bta.R$menu
Warning: com.bta.R: can't find referenced class com.bta.R$string
Warning: com.bta.myapp.MyAppActivity$1: can't find referenced class com.bta.myapp.MyAppActivity
Warning: com.bta.myapp.MyAppActivity$ELicenseResponse: can't find referenced class com.bta.myapp.MyAppActivity
Warning: com.bta.myapp.MyAppActivity$MyLicenseCheckerCallback$1: can't find referenced class com.bta.myapp.MyAppActivity$MyLicenseCheckerCallback
Warning: com.bta.myapp.MyAppActivity$MyLicenseCheckerCallback$1: can't find referenced class com.bta.myapp.MyAppActivity
Warning: com.bta.myapp.R$array: can't find referenced class com.bta.myapp.R
Warning: com.bta.myapp.R$layout: can't find referenced class com.bta.myapp.R
Warning: com.bta.myapp.R$xml: can't find referenced class com.bta.myapp.R
Warning: there were 49 unresolved references to classes or interfaces.
         You may need to specify additional library jars (using '-libraryjars').
java.io.IOException: Please correct the above warnings first.
    at proguard.Initializer.execute(Initializer.java:321)
    at proguard.ProGuard.initialize(ProGuard.java:212)
    at proguard.ProGuard.execute(ProGuard.java:87)
    at proguard.ProGuard.main(ProGuard.java:493)

I did notice the recommendation to add -libraryjars in proguard.cfg, but I never needed to do this before (and I didn't change anything in my code, all I did was updating Proguard from 4.6 to 4.8). Does this suggest something wrong in my development environment configuration?

Also, I checked Proguard's Troubleshooting section for Can't find referenced class: It refers to forgetting or ignoring to specify a library via -libraryjars (which I admit), but I never specified any library and it always worked before! What changed?

My proguard.cfg file BTW starts with:

-optimizationpasses 5
-dontusemixedcaseclassnames
-dontskipnonpubliclibraryclasses
-dontpreverify
-verbose
-optimizations !code/simplification/arithmetic,!field/*,!class/merging/*

Any idea what's going on? Why did Proguard start giving me such hard time? (I coasted very smoothly with it for over a year now) Is there something fundamental I am missing in my system configuration?

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.

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.

Eclipse keeps Building workspace... and Building workspace... and Building workspace

9 votes

Why would Eclipse, when building an Android project, get stuck in an infinite loop for Building workspace... and (re) Building workspace... and (re) Building workspace...

Is this a known bug?

What is the proper way to get out of this loop?

Notes:

  1. If I uncheck Project > Build Automatically, it builds fine and even exports a perfectly running signed release APK.
  2. This problem only started after I upgraded to the latest SDK r19. Prior to that (SDK r11) I never experienced this problem.
  3. Bug 160868 describes exactly this problem. But hasn't it being solved since then?
  4. A similar problem description found here but like the previous one, it's old and not directly related to Android development.
  5. Issue 27940 suggests a bug in handling a const named BuildConfig.DEBUG which may or may not be related. But hasn't it been fixed in r18???
  6. I found this great tip for auto tagging / date-stamping in the Android build system, but I am not using anything like that, in addition to double-checking and verifying that builders come at the right order the Project builders list order (same order as other projects that do not exhibit this infinite-loop build behavior).
  7. My hunch tells me there might be a lock-file or flag that somehow got stuck (read-only mode?) and thus confuses the build system. Any idea what that boolean may be and where to find it?
  8. If I first open another project in the same workspace (that doesn't exhibit this problem), the project that has this problem miraculously stops the infinite rebuilding. This doesn't happen if I reverse the order of which project is opened first. Does this imply gremlins in the Eclipse/SDK/ADT build system?

No "blind shooting" please: answer this question only if you have personally experienced this amazing phenomenon (and solved it) or can point to an article that experienced this amazing phenomenon (and solved it).

Turns out bug 27940 hasn't been fixed yet.

I use the following workaround:

  1. Disable "Project > Build Automatically"
  2. Project > Clean
  3. Project > Build All