Failed automated Android UI-Tests on Jenkins-Server due to complex lib-project dependencies of the main project(s)

Question

Shortly summerized, my project structure is like follows:
- A and B are android lib-projects, where B depends on A
- C (normal android project) depends on B
- T is test-project of C

I have correspondingly two projects on my jenkins server, one for C and one for T, which have their own script for build, using actually just android and ant commands. So there is no problem with the build of C, but i can't get work build of T.

"Work" should there mean, that, depending on the script, it either don't compile or do fail at runtime because of some missing classes, that actually could't be, or don't pass the dexing phase because of adding duplicates.

So it's clear, that there is something wrong with the dependencies, but the interesting thing is that it works very nice on local machine with eclipse & on emulator.

So here an example shell-script code, that actually should work and create an apk-file:

cd project-test
android update test-project -m ../projectC -p .
ant clean debug

This causes unfortunately that some classes from from B, that i'm also going to test, couldn't be found from the java compiler and i get always error like this:

...
[javac] Compiling 14 source files to /home/mehmed/git/project/test-project/bin/classes
[javac] SomeActivityTest.java:8: package com.mydomain.portal.android.project.activity does not exist
[javac] import com.mydomain.portal.android.project.activity.SomeClass1;
[javac]                                                        ^
[javac] SomeActivityTest.java:9: package com.mydomain.portal.android.project.data does not exist
[javac] import com.mydomain.portal.android.project.data.SomeClass2;
[javac]                                                    ^
[javac] SomeActivityTest.java:10: package com.project.portal.android.project.util does not exist
[javac] import com.mydomain.portal.android.project.util.SomeClass3;
[javac]                                                    ^
...

I did try almost everything possible to fix that, even manually editing the project.properties file and including just B or B and C at the same time as lib-projects like this:

cd project-test
android update test-project -m ../projectC -p .
echo "android.library.reference.1=../projectB" >> project.properties
# or even also projectA:
echo "android.library.reference.2=../projectA" >> project.properties
ant clean debug

which results this time in dexing errors because of duplicate adding of the classes from lib-projects.

Does somebody have any ideas about fixing this? Thanks for help in advance!

Answer 1

In your Test Project T, if you have SomeActivityTest that explicitly import/use some package/class from Library Project B and/or C, you have to add the Library Project as a dependency of Test project, as the referenced package/class is required at project build time. if you don't, you will get the following error when compile you Test Project:

[javac] SomeActivityTest.java:8: package com.mydomain.portal.android.project.activity does not exist
[javac] import com.mydomain.portal.android.project.activity.SomeClass1;
[javac]                                                        ^
[javac] SomeActivityTest.java:9: package com.mydomain.portal.android.project.data does not exist

If you add Library Project as dependency in both Main Project and Test Project, and use Ant build you test project, it cause duplicate entries at dexing step. Eclipse ADT plugin knows how to hanlde this situation properly so you don't get this trouble when build with Eclipse:

[dx] UNEXPECTED TOP-LEVEL EXCEPTION:
[dx] java.lang.IllegalArgumentException: already added: Lcom/mydomain/...;
[dx]     at com.android.dx.dex.file.ClassDefsSection.add(ClassDefsSection.java:123)
[dx]     at com.android.dx.dex.file.DexFile.add(DexFile.java:163)

Currently, there is a workaround (dirty fix in ant script), check out my answer here for details.

Note that the most recent SDK release r17 which got many bug fix and improvement. According to the changelog, it claims that now SDK can deal with duplicate dependencies more smarter, although I haven't tired myself with Test Project yet. Probably you can give it a shot and see if it works. Hope this helps.