Recent Changes‎ > ‎

Dealing with dependencies in Android Eclipse projects

posted Mar 9, 2012, 2:35 PM by Xavier Ducrohet   [ updated Feb 7, 2017, 8:41 AM by smain@google.com ]


Note: This page is about the deprecated plugin for Eclipse. For documentation about using dependencies in Android Studio, instead see https://developer.android.com/studio/build/dependencies.html

If you're still using Eclipse, see our Android Studio migration guide.



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:
  • 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.