title: Android unit test using ant with library project
body: <p>It seems that also the latest android SDK tools still don't properly support testing of applications that contain linked library projects.</p>
  
  <p>I have a project with the following setup:</p>
  
  <p>TestLib (android library project) &lt;- TestMain (android project) &lt;- TestMainTest (android unit test project)</p>
  
  <p>I created all those projects in eclipse and then used <code>android update (test-/lib-)project ...</code> to generate the <code>build.xml</code> et. al.</p>
  
  <p>The problem starts as soon as you have a class in TestMain (<code>InheritAddition.java</code> in my example) that inherits from a class in TestLib (<code>Addition.java</code>) and you want to reference this class in the unit test (<code>InheritAdditionTest.java</code>).</p>
  
  <h2>TestLib</h2>
  
  <pre><code>public class Addition {
      public int add2(int o1, int o2) {
        return o1 + o2;
      }
  }
  </code></pre>
  
  <h2>TestMain</h2>
  
  <pre><code>public class InheritAddition extends Addition {
      public int sub(int p1, int p2) {
          return p1 - p2;
      }
  }
  </code></pre>
  
  <h2>TestMainTest</h2>
  
  <pre><code>public class InheritAdditionTest extends AndroidTestCase {
      public void testSub() {
          Assert.assertEquals(2, new InheritAddition().sub(3, 1));
      }
  }
  </code></pre>
  
  <p>When building on the command line the result is the following:</p>
  
  <pre>
  W/ClassPathPackageInfoSource(14871): Caused by: java.lang.NoClassDefFoundError: org/test/main/InheritAddition
  W/ClassPathPackageInfoSource(14871):    ... 26 more
  W/ClassPathPackageInfoSource(14871): Caused by: java.lang.IllegalAccessError: Class ref in pre-verified class resolved to unexpected implementation
  W/ClassPathPackageInfoSource(14871):    at dalvik.system.DexFile.defineClass(Native Method)
  W/ClassPathPackageInfoSource(14871):    at dalvik.system.DexFile.loadClassBinaryName(DexFile.java:195)
  W/ClassPathPackageInfoSource(14871):    at dalvik.system.DexPathList.findClass(DexPathList.java:315)
  W/ClassPathPackageInfoSource(14871):    at dalvik.system.BaseDexClassLoader.findClass(BaseDexClassLoader.java:58)
  W/ClassPathPackageInfoSource(14871):    at java.lang.ClassLoader.loadClass(ClassLoader.java:501)
  W/ClassPathPackageInfoSource(14871):    at java.lang.ClassLoader.loadClass(ClassLoader.java:461)
  W/ClassPathPackageInfoSource(14871):    ... 26 more
  W/dalvikvm(14871): Class resolved by unexpected DEX: Lorg/test/main/InheritAddition;(0x41356250):0x13772e0 ref [Lorg/test/lib/Addition;] Lorg/test/lib/Addition;(0x41356250):0x13ba910
  </pre>
  
  <p>I found some workaround that works for eclipse:</p>
  
  <p><a href="https://stackoverflow.com/questions/2472059/cant-build-and-run-an-android-test-project-created-using-ant-create-test-proje">Can&#39;t build and run an android test project created using &quot;ant create test-project&quot; when tested project has jars in libs directory</a></p>
  
  <p>That does the trick, but I am looking for a solution that works with ANT (more precisely I am looking for a solution that works on both at the same time).</p>
  
  <p>The documented approach (by changing build.xml to include jars from the main project into the class path) is not applicable here as the sample project doesn't use any library jars (also I believe that this particular problem is now fixed with SDK tools r16).</p>
  
  <p>I guess the brute force way of solving that is to try and somehow remove the dependencies of <code>TestMainTest</code> to <code>TestLib</code> (by modifying <code>project.properties</code>) and instead manage to hack the build script to put those built jars into the class path (so replace the <code>-compile</code> target with something that modifies the class path for <code>javac</code>). Since I have a long history of trying to keep up with android SDK toolchain changes, this is not really my favorite option as it is a) rather complicated and b) requires constant modification of the <code>build.xml</code> whenever the toolchain changes (which is quite frequently).</p>
  
  <p>So I am looking for ideas of how to get such a setup working without using the sledge hammer. Maybe I am missing something totally obvious but for me this use case is fairly standard and I have a hard time understanding why this isn't supported out of the box.</p>