arece que as ferramentas mais recentes do SDK para Android ainda não suportam adequadamente o teste de aplicativos que contêm projetos de bibliotecas vinculada

Tenho um projeto com a seguinte configuração:

TestLib (projeto da biblioteca android) <- TestMain (projeto android) <- TestMainTest (projeto de teste da unidade android)

Criei todos esses projetos no eclipse e useiandroid update (test-/lib-)project ... para gerar obuild.xml et. al.

O problema começa assim que você tem uma classe no TestMain InheritAddition.java no meu exemplo) que herda de uma classe no TestLib Addition.java) e você deseja referenciar esta classe no teste de unidade InheritAdditionTest.java).

TestLib

public class Addition {
    public int add2(int o1, int o2) {
      return o1 + o2;
    }
}

TestMain

public class InheritAddition extends Addition {
    public int sub(int p1, int p2) {
        return p1 - p2;
    }
}

TestMainTest

public class InheritAdditionTest extends AndroidTestCase {
    public void testSub() {
        Assert.assertEquals(2, new InheritAddition().sub(3, 1));
    }
}

Ao criar na linha de comando, o resultado é o seguinte:

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

Encontrei uma solução alternativa que funciona para o eclipse:

Não é possível criar e executar um projeto de teste do Android criado usando "ant create test-project" quando o projeto testado possui jars no diretório libs

Isso faz o truque, mas estou procurando uma solução que funcione com a ANT (mais precisamente, estou procurando uma solução que funcione nos dois ao mesmo tempo

A abordagem documentada (alterando build.xml para incluir jars do projeto principal no caminho da classe) não é aplicável aqui, pois o projeto de amostra não usa nenhum jars da biblioteca (também acredito que esse problema específico agora seja corrigido com o SDK ferramentas r16).

Acho que a maneira de resolver a força bruta é tentar remover de alguma forma as dependências deTestMainTest paraTestLib (modificandoproject.properties) e, em vez disso, consiga hackear o script de compilação para colocar os jars criados no caminho da classe (substitua o-compile target com algo que modifica o caminho da classe parajavac). Como tenho um longo histórico de tentativas de acompanhar as alterações na cadeia de ferramentas do SDK do Android, essa não é realmente a minha opção favorita, pois é a) bastante complicada eb) requer modificações constantes build.xml sempre que a cadeia de ferramentas mudar (o que é bastante frequente

Então, estou procurando idéias de como fazer com que essa configuração funcione sem usar a marreta. Talvez esteja faltando algo totalmente óbvio, mas para mim esse caso de uso é bastante padrão e tenho dificuldade em entender por que isso não é suportado imediatament