Android-SDK r17 ruins working projects

Question

I have updated my android-sdk-package from r16 to r17. I have updated the Eclipse ADT-Plugin too.
My project worked perfectly fine with r16 (android-sdk r16 and Eclipse ADT Plugin v16), but now the app does not start: The Classloader can not find the MainActivity. The MainActivity is the first activity, that starts (it is properly declared in the AndroidManifest).

03-22 15:07:28.984: E/AndroidRuntime(22106): Caused by: java.lang.ClassNotFoundException: my.....MainActivity
03-22 15:07:28.984: E/AndroidRuntime(22106):    at dalvik.system.BaseDexClassLoader.findClass(BaseDexClassLoader.java:61)
03-22 15:07:28.984: E/AndroidRuntime(22106):    at java.lang.ClassLoader.loadClass(ClassLoader.java:501)
03-22 15:07:28.984: E/AndroidRuntime(22106):    at java.lang.ClassLoader.loadClass(ClassLoader.java:461)
03-22 15:07:28.984: E/AndroidRuntime(22106):    at android.app.Instrumentation.newActivity(Instrumentation.java:1023)
03-22 15:07:28.984: E/AndroidRuntime(22106):    at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:1871) 

The package name is 100% right. I even checked out a tagged version of my project (I have release the project and I always tag my versions) and tryed it: same result.
What I have already tried (I use Arch Linux):
- delete android-sdk + android-sdk-platform-tools (and reinstall them)
- delete the entire android-folder (/opt/android-sdk) and reinstall the packages, download the target platform
- delete ~/.android
- delete ~/.eclipse
- reinstall Eclipse ADT-Plugin
- recreate Virtual Devices
- create a new project (the new project works)
- unpack the .apk-file and view the compiled classes with dexdump: the apk-file contains the MainActivity
- I read the Android-SDK-Release-Notes for something related, but I didn't find anything
- And of course, rebuild the project (clean + build, I even manually deleted the bin-folder)

The only thing that really worked was to switch on my notebook (still android-sdk r16).
So... what am I doing wrong? It's probably something simple...

Thanks!

Schopenhauer

Small addition for the "clean + build" step: Closing and re-opening the project sometimes help forcing Eclipse/ADT plugin to regenerate everything. – Forgat

Answer 1

As has been reported here and elsewhere, you need to ensure that any third-party JARs you are using live in libs/, both in your project and in any dependent library projects. Try that and see if it helps.

Cosmos

Thank you very much. I knew it was something stupid... Google should point that out on their homepage. I didn't even think about third party JARs. – Schopenhauer

Thanks for this information. So even for general experimental, Eclipse, debug only builds for the emulator, every project that needs a particular 3rd party jar needs its own copy rather than referencing a central location? This seems a retrograde step to me. – Formica

@NickT: If you are using an OS that supports symlinks, those might work. – Cosmos

I'd just thought about that. My Linux box is too underpowered for Android work, so I'm stuck with Windows. I'm wondering if the ${external.libs.absolute.dir} that appeared recently might be a fix for this that they forgot to document. This just goes against the grain for me, it's bad practice, pure and simple. – Formica

@NickT: "My Linux box is too underpowered for Android work, so I'm stuck with Windows" -- if I knew your address, I'd send you a sympathy card. :-) "I'm wondering if the ${external.libs.absolute.dir} that appeared recently might be a fix for this that they forgot to document" -- I know diddly about how the Eclipse build process works, so I haven't a clue, sorry. – Cosmos

+1: Works lik a charm, specially this 2nd lvl link in the article helpe me android.foxykeep.com/dev/… – Lamont

Answer 2

For those developers using straight Ant builds with a custom build.xml which has overridden targets which refer to "jar.libs.ref", you should note that this has been replaced, so your build will fail.

Changing this to "project.libraries.jars" worked for my targets, but you should probably check the diffs between the previous sdk/tools/ant/build.xml and the new one. It's always worth taking a copy of this before you upgrade the SDK tools, as the Ant builds quite often get broken by the upgrade process.

Formica

Answer 3

Sometimes beside closing/re-opening project eclipse restart is necessary to make everything work as planned and expected. Especially if you updated any of component. But of course as CommonsWare mentioned library folder adjustment is mandatory.

Found

Answer 4

This topic is also being discussed at the android-developers forum. The magic recipe that worked for me was this: In addition to re-homing included libraries, I had to change my target SDK in Project Properties away from 4.0.3 and back again. That fixed it.

Osburn

Answer 5

If you are not using Maven here is the detailed guide with pictures, like mentioned from CommonsWare.

http://android.foxykeep.com/dev/how-to-fix-the-classdefnotfounderror-with-adt-17

But if you are using Maven dependencies are not included with the library project m2e-android connector still does not know how to handle this, so if you have Android projects with Maven don't update to ADT 17.

The new 0.4.1 version of the Android Connector for M2E (m2e-android) has been released and a bug with Maven projects are fixed. https://github.com/rgladwell/m2e-android/issues/72

Josefjosefa

Answer 6

I tripped up over the same error when using the ADT 18. There were several causes, including having to move my jar files from a lib to a libs folder. Coincidentally I was using a new workstation with JDK 7 installed. It took me several hours to fathom out that the dex build step was rejecting the compiled class files from one of the jar files I built separately because the class signature was unacceptable. The error reported by the dex build step was "trouble processing: bad class file magic (cafebabe) or version (0033.0000)"

My jar file consists of pure Java code which I build using ant. Cutting a long story short, I finally managed to get everything to work once I installed Java 6's JDK, added the path to the JDK 6 bin folder as the first item in my path statement & then rebuilt the jar file. I was then able to use the jar file in my Android project. The dex build step didn't reject the classes from the jar file and therefore my app ran on the device rather than failing with a ClassNotFoundException.

I discovered several helpful tips: - Run ant with the -v command line option and scrutinize the output carefully. That's how I knew the java6 compiler was being used at the end of all my changes. And similarly when I built the Android app using ant, the dex stage had enough detail to tell me which jar files it processed, etc.

Similarly in Eclipse I enabled the verbose level of logging for the Android build output. Preferences>Android>Build>Build output> Verbose

adb logcat output actually reports the missing class files when it loads the app. If you're using the LogCat view in Eclipse the relevant lines are in red text and easy to spot once you know they exist.

I hope this helps others in a similar predicament to one I found myself in - where I created my own pure java jar files. Several factors had changed including the Java SDK version and the ADT tools, and diagnosing the various causes was a challenge.

Gaffney