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 in project.properties, a project’s classpath is automatically populated with:
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:
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.
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:
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.
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.
Special case for android-support-v4.jar and android-support-v13.jar.