隨手亂寫

在使用ZBar所附的example code時，遇到了Could not find class 'net.sourceforge.zbar.ImageScanner'

這個問題在某些情況之下需要更改Eclipse裡頭的設定，Project->Properties->Java Build Path->Order and Export

裡面的順序有時候會有相關性，有些library需要把check box勾選起來才有辦法解決

但我在試了這些方法都沒用之後，在爬文爬到某個討論區時發現下面這個issue

原文出處

So I updated my SDK and ADT to version 17 and once again I got a big problem :)

Every project I have which use JAR libraries could still be built without problems but as soon as they start on the phone, they crashed with the following error :

03-21 19:20:56.455: E/AndroidRuntime(24471): FATAL EXCEPTION: main
03-21 19:20:56.455: E/AndroidRuntime(24471): java.lang.NoClassDefFoundError: org.acra.ACRA
03-21 19:20:56.455: E/AndroidRuntime(24471): at com.foxykeep.myproject.HomeActivity.onCreate(MyProjectApplication.java:127)
03-21 19:20:56.455: E/AndroidRuntime(24471): at android.app.Instrumentation.callApplicationOnCreate(Instrumentation.java:969)
03-21 19:20:56.455: E/AndroidRuntime(24471): at android.app.ActivityThread.handleBindApplication(ActivityThread.java:3925)
03-21 19:20:56.455: E/AndroidRuntime(24471): at android.app.ActivityThread.access$1300(ActivityThread.java:122)
03-21 19:20:56.455: E/AndroidRuntime(24471): at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1184)
03-21 19:20:56.455: E/AndroidRuntime(24471): at android.os.Handler.dispatchMessage(Handler.java:99)
03-21 19:20:56.455: E/AndroidRuntime(24471): at android.os.Looper.loop(Looper.java:137)
03-21 19:20:56.455: E/AndroidRuntime(24471): at android.app.ActivityThread.main(ActivityThread.java:4340)
03-21 19:20:56.455: E/AndroidRuntime(24471): at java.lang.reflect.Method.invokeNative(Native Method)
03-21 19:20:56.455: E/AndroidRuntime(24471): at java.lang.reflect.Method.invoke(Method.java:511)
03-21 19:20:56.455: E/AndroidRuntime(24471): at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:784)
03-21 19:20:56.455: E/AndroidRuntime(24471): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:551)
03-21 19:20:56.455: E/AndroidRuntime(24471): at dalvik.system.NativeStart.main(Native Method)

I asked Xavier Ducrohet and Tor Norbye (both working on the ADT plugin) on Google+ about the error and they linked to this page which explains how to solve the problem but is not ultra clear (at least for me).

So here is the same solution but explained with screenshots so we can see more easily what changed  :

From left to right, we have :

• My project with ADT 16 (the small graphic changes are due to the fact the left image is from Eclipse Windows while the 2 on the right are from Eclipse Mac)
• My project with ADT 17 before the fix
• My project with ADT 17 after the fix

What I did to fix the bug was :

• Remove the libraries from the standard Java build path :
• Right click on the project name > Properties > Java Build Path > tab Libraries > remove everything except the “Android X.X” (2.3.3 in my case) and the “Android Dependencies”
• Rename the libraries folder from “lib” to “libs”
• By doing that, all the libraries in the folder “libs” are found by the Android plugin and are added to the “Android Dependencies” item of the project
• Clean the project (not exactly needed)
• You are good to go !

This problem is due to the fact that libraries are not managed the same way with the new ADT build.
Instead of having 2 different managements of libraries (one for Android Library Projects, one for the standard jars), now both are merged into the Android Dependencies item.

Other info, the annotations.jar file is for the new lint Java annotations (more info here : http://tools.android.com/recent/ignoringlintwarnings)
Besides this small problem, the ADT version 17 looks really good and I love the new things added to the lint checks !!

[Update]

The DroidUX Team found another solution to fix the problem. I didn’t test it personally but it don’t see why it shouldn’t work : 

Hi,

Just to add to the solution:

If you have references to jars that are not in the ‘libs’ folder, for example if you use ‘classpath variable’, you can resolve the NoClassDefFoundError issue with the new ADT 17 by exporting the references.

To export the references: simply go to “Properties > Java Build Path > Order and Export”, and check all the references you want exported.

我才發覺到，我好像沒有照example code裡頭readme的指示，在project裡頭增加一個"libs" folder，雖然用到zbar libary有import進來，也有加到build path裡頭

但相同的問題總是一再發生，後來加了libs folder後，這問題就不見了，看來ADT的環境裡頭，也有一些已定義好的潛規則要遵守

後來查了一下，發現ant-based build system 只會把名為"libs" folder裡頭的jar file包到apk裡頭

原文出處

Dealing with dependencies in Android projects

posted Mar 9, 2012, 2:35 PM by Xavier Ducrohet   [ updated Mar 28, 2012, 1:22 PM ]

In revision 17 of the Android SDK Tools and of the Eclipse ADT plug-in, we have made a lot of improvements to the dependency management of Android projects. The first thing we changed was to align both the Ant-based build system and the Eclipse plug-in so that they behave the same. Projects have source folders, as well as Library Project and jar file dependencies. With no other setup needed than adding Library Projects as a dependency inproject.properties, a project’s classpath is automatically populated with: The content of the project’s libs/*.jar The output of the Library Projects. The Library Projects’ libs/*.jar These items, plus the output of the compilation of the project’s own source code, are sent to dex for bytecode conversion and inclusion in the final APK. Because a project could depend on several libraries using the same jar files, the build system now looks at all the required jar files, detects duplicates coming from different libraries and removes them. This will prevent the dreaded “already added” error from dx. See below for how duplicates are found. Important change: We have changed the way Library Projects generate and package R classes: The R class is not packaged in the jar output of Library Projects anymore. Library Project do not generate the R class for Library Projects they depend on. Only main application projects generates the Library R classes alongside their own. This means that library projects cannot import the R class from another library project they depend on. This is not necessary anyway, as their own R class includes all the necessary resources. Note that app projects can still import the R classes from referenced Library Projects, but again, this is not needed as their own R classes include all the resources. Eclipse specific changes The dynamic classpath container called “Library Projects” has been renamed to “Android Dependencies” as it now contains more than just Library Projects. The container will now also be populated with Java-only projects that are referenced by Library Projects. If those Java projects also reference other Java projects and/or jar files they will be added automatically (jar files referenced through user libraries are supported as well). Important: this only happens if the references are set to be exported in the referencing project. Note that this is not the default when adding a project or jar file to a project build path. Library Projects (and the content of their libs/*.jar files) is always exported.   Important: If you are still referencing jar libraries manually instead of putting them under libs/ be aware of the following: If the project is a Library project, these jar libraries will not be automatically visible to application projects. You should really move these to libs/ If the project is an application, this can work but you must make sure to mark the jar files as exported.   Here's how to mark Java project and jar libraries as exported (the Android Dependencies container does not have to be marked as exported, it is always exported anyway): Again, duplicates (both projects and jar files) are detected and removed. Dependency resolution When a project references two Library projects that both require the same jar file, the build system has to detect and resolve the duplication. A full dependency system would associate each jar file with a fully qualified name and a version number to figure out which version to use. Unfortunately the Android build system does not have a full dependency resolution system (yet). In the meantime we have implemented a very basic system that follows these rules: Jar file are identified strictly by their file names. This means mylib.jar is different than mylib-v2.jar and both will be packaged, possibly resulting in “already added” dx error if they are actually the same library in a different revision. For jars with the same file name, “same version” means same exact file. Currently our detection is very basic, checking only that the files are identical in size and sha1. If two libraries each include in their libs folder a file called mylib.jar but these two files are different, then the build system will fail indicating a dependency error.   The solution is to make sure the two jar files are actually the same one if they are the same library or to rename them if they are different libraries. Special case for android-support-v4.jar and android-support-v13.jar. We make a special case for these two libraries because -v13 contains a full version of -v4 inside. If both are found, then only -v13 will be used.   Note that we can’t guarantee that the version of -v4 inside -v13 is the same as version used by the other libraries. We recommend that when you update your project with a newer version of the support library, you update all of your projects at the same time, whether they use -v4 or -v13.