Android java.lang.VerifyError?

No meu aplicativo Android, sempre recebo VerifyErrors! E não consigo descobrir por quê. Sempre que incluo um JAR externo, sempre recebo VerifyErrors quando tento iniciar meu aplicativo (exceto uma vez, quando incluí Apache Log4j.)

Normalmente consigo contornar isso pegando o código-fonte da biblioteca e adicionando-o ao meu projeto, mas estou tentando colocar a biblioteca cliente GData .

Posso obter isso no código-fonte, mas não consigo em dependências (mail.jar, activation.jar, servlet-api.jar), então recebo erros de verificação. Eu gostaria de chegar à raiz desse problema de uma vez por todas. Procurei na internet, mas todos parecem falar de arquivos de aula incompletos? que eu não conheço.

O Android usa um formato de arquivo de classe diferente. Você está executando os arquivos JAR de terceiros por meio da ferramenta "dx" que acompanha o Android SDK?

Olhe para LogCat e veja o que está causando o erro de verificação. Provavelmente é algum método em uma classe java.lang que não é compatível com o nível do Android SDK que você está usando (por exemplo, String.isEmpty ()).

De android-developers :

A saída de "adb logcat" indica a classe que não pôde ser encontrada, bem como a classe que possui a referência incorreta. A localização é identificada até a instrução Dalvik específica. O truque é olhar nos logs acima da exceção.

Para fazê-lo funcionar, você precisa adicionar jar da biblioteca a uma das pastas de origem (mesmo se já tiver adicionado como biblioteca eclipse, ainda será necessário adicioná-lo como fonte).

1. Crie um diretório em seu projeto (ex "libs") e coloque o jar da biblioteca nele.
2. Adicione o diretório ao caminho da classe de construção (clique com o botão direito na pasta e selecione "Build path" -> "Use as source folder").
3. Reconstrua seu projeto.

Aconteceu comigo agora. O erro foi causado porque eu estava usando métodos de um SDK mais recente que meu dispositivo tinha.

O dispositivo Android 1.5 instalou um apk usando este:

<uses-sdk android:minSdkVersion="3" android:targetSdkVersion="4"/>

Encontrei um caso interessante. Eu uso:

<uses-sdk
   android:minSdkVersion="9"
   android:targetSdkVersion="18" />

Portanto, alguns dos novos recursos do Android 4 não estão implementados no Android 2.3 como ImageView.setLayerType. Para evitar erros de tempo de execução simplesmente:

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.HONEYCOMB) {
   setLayerType(View.LAYER_TYPE_SOFTWARE, null);
}

Essa abordagem deve ser usada também com tratamento de exceções:

} catch (NetworkOnMainThreadException nomte) {
   // log this exception
} catch (SocketTimeoutException socketTimeoutException) {
   // log this exception
}

NetworkOnMainThreadExceptionnão é implementado no Android 2.3, portanto, quando a classe é carregada (e não antes!), java.lang.VerifyErrorocorre a exceção .

Se você estiver usando Retrolambda, pode ter adicionado um método estático a uma interface (que só é permitido no Java 8).

Isso também pode ocorrer devido ao erro de limite de referência no Lollypop abaixo das versões, onde é limitado a um tamanho máximo de 65K

Possível solução para o problema acima

Passo 1: Add android-support-multidex.jar to your project. The jar can be found in your Android SDK folder /sdk/extras/android/support/multidex/library/libs

Passo 2: Estenda seu aplicativo com MultiDexApplication, por exemplo

public class MyApplication extends MultiDexApplication

Etapa 3: Substituir attachBaseContext

protected void attachBaseContext(Context base) {
 super.attachBaseContext(base);
 MultiDex.install(this);
}

Etapa 4: a próxima etapa é adicionar o seguinte à parte android de seus apps build.gradle

 dexOptions {
      preDexLibraries = false
   }

Etapa 5: por último, seguindo para a parte geral de seus aplicativos build.gradle

afterEvaluate {
   tasks.matching {
      it.name.startsWith('dex')
   }.each { dx ->
      if (dx.additionalParameters == null) {
         dx.additionalParameters = ['--multi-dex']
      } else {
         dx.additionalParameters += '--multi-dex'
      }
   }
}

Para obter detalhes, verifique

https://developer.android.com/tools/building/multidex.html

No meu caso, aconteceu quando eu atualizei do Eclipse Indigo para o Eclipse Juno: Não tenho certeza qual é o verdadeiro motivo, mas meu projeto Android no qual estou trabalhando há muito tempo parou de funcionar por causa dessa exceção.

Depois de muitas horas tentando consertar isso, encontrei a solução para mim.

Em meu projeto Android, uso outro projeto (digamos, "MyUtils") que está no mesmo espaço de trabalho. Então, eu precisava fazer o seguinte:

Clique com o botão direito do mouse em projeto Android -> Caminho de construção -> Configurar caminho de construção

Agora, vá para a aba "Order and Export" e marque "MyUtils". É isso: me livrei dessa exceção irritante.

Eu fiz downgrade da versão do Gradle 2.0.0-alpha2 para 1.5.0 que resolveu este problema.

O problema também pode ser causado por uma incompatibilidade entre dois projetos de andróides. Por exemplo, se você desenvolveu uma biblioteca android usando o pacote "com.yourcompany", então você tem o projeto do aplicativo principal usando o mesmo pacote do pacote base. Então, digamos que você queira alterar a versão do seu aplicativo principal, então você altera os valores do arquivo de manifesto: Código da versão e nome da versão. Se você executar seu aplicativo sem alterar esses valores para a biblioteca, receberá um erro de verificação em qualquer chamada de um método em um objeto da biblioteca.

Eu tive o mesmo problema. Eu estava construindo com 2.1 r1 e atualizei para 2.1 r3 com o novo adt 17. Eu verifiquei erros no mail.jar do javamail e isso estava me deixando louco. Aqui está como resolvi o problema:

1. criou uma pasta / libs e adicionou os jars.
2. clique com o botão direito> adicionar como pasta de origem

Eu tentei reconstruir e falhou. Eu removi o diretório libs / como uma pasta de origem e removi refs para os 3 arquivos jar no caminho de construção. Em seguida, adicionei a pasta / libs novamente e adicionei cada jar na pasta / libs ao caminho de construção. Agora funciona conforme o esperado. Esta é uma solução alternativa estranha, mas funcionou para mim.

Em Eclipse 4.x, se você encontrar este problema, tente abaixo:

1. migrar todos os jars de terceiros incluídos para o User-Libaray
2. mova a biblioteca do usuário antes da biblioteca do Android e verifique-a na guia Pedido e exportação
3. limpar e reconstruir para funcionar

Eu tenho esse problema após uma atualização do SDK. O compilador teve problemas com minhas bibliotecas externas. Fiz isso: clique com o botão direito do mouse no projeto e em "android Tools> add suport library ..." instale na minha biblioteca de projeto "android-support-v4.jar".

java.lang.VerifyErrorsignifica que seu bytecode compilado está se referindo a algo que o Android não consegue encontrar em tempo de execução. Este verifyError me envia apenas o kitkat4.4 e a versão inferior que não está na versão anterior, mesmo que executei a mesma compilação em ambos os dispositivos. quando usei o analisador jackson json de uma versão mais antiga, ele mostrajava.lang.VerifyError

compile 'com.fasterxml.jackson.core:jackson-databind:2.2.+'
compile 'com.fasterxml.jackson.core:jackson-core:2.2.+'
compile 'com.fasterxml.jackson.core:jackson-annotations:2.2.+'

Em seguida, mudei a Dependancy para a versão mais recente 2.2 para 2.7 sem a biblioteca principal (quando incluo core2.7, ela fornece o verifyError), então funciona. o que significa que os métodos e outros conteúdos do núcleo são migrados para a versão mais recente do Databind2.7 . Isso corrige meus problemas.

compile 'com.fasterxml.jackson.core:jackson-annotations:2.7.0-rc3'
compile 'com.fasterxml.jackson.core:jackson-databind:2.7.0-rc3'

Também recebo o VerfiyError ... não consigo encontrar um motivo real. Ajuda a envolver as novas linhas de código em um método (Eclipse, 'Extrair Método ...'). Portanto, no meu caso, o motivo não é um método sem suporte.

Eu tive um problema muito semelhante. Eu tinha adicionado jars Apache POI e um problema apareceu quando eu atualizei para Android SDK 22.3.

Eu tinha as bibliotecas privadas do Android verificadas, então esse não era o problema comum com o Android SDK. Desmarquei todos os jars Apache POI e adicionei um por um. Descobri que poi-3.9-20121203.jar deve ser anterior a poi-ooxml-3.9-20121203.jar . Caso contrário, não funcionará.

Se você tiver testes, tente comentar esta linha de seu build.gradearquivo:

testCoverageEnabled = true

Para mim, isso causou exceções VerifyError em classes que usam recursos Java 1.7, particularmente instruções de troca de string.

Eu tive o mesmo problema depois de fazer um git pull.

Solução: Build -> Clean Project.

Espero que isto ajude.

Eu encontrei outro caso.

Condições:

• Use Retrolambda (não tenho certeza se é necessário);
• Faça um método estático em uma interface.

E o resultado é boom! java.lang.VerifyError ao tentar acessar a classe que usa essa interface. Parece que o Android (4.4. * No meu caso) não gosta de métodos estáticos em interfaces. Remover o método estático da interface faz o VerifyError desaparecer.

Eu também tive esse problema, assim como meus jars em uma biblioteca de usuário ...

A maneira como resolvi isso foi adicioná-los à pasta lib e, em seguida, adicioná-los nas propriedades de compilação no eclipse ...

A primeira vez que fiz isso não funcionou, mas depois eu removi e readicionei e começou a funcionar ...

um pouco estranho! mas agora trabalhando o tempo todo.

Boa sorte

Codifiquei métodos / classes de API do Android que estão no SDK 2.1 e estava tentando executá-los no emulador de Android 1.6. Então, eu entendi esse erro.

SOLUÇÃO: Alterado para corrigir a versão do emulador.

ISSO FUNCIONOU PARA MIM .. Obrigado.

Para a posteridade, recebi este erro porque estava usando Arrays.copyOf()um método que não é compatível com Java 1.5, que corresponde ao Android Nível 4. Como estava executando incluindo bibliotecas desenvolvidas em 1.6, elas compilaram bem. Eu só vi os problemas quando movi a classe em questão para o meu projeto Android - então o erro foi destacado.

Uncaught handler: thread main exiting due to uncaught exception
java.lang.VerifyError: com.j256.ormlite.dao.BaseDaoImpl$DaoConfigArray
  at com.j256.ormlite.dao.BaseDaoImpl$1.initialValue(BaseDaoImpl.java:71)
  at com.j256.ormlite.dao.BaseDaoImpl$1.initialValue(BaseDaoImpl.java:1)
  at java.lang.ThreadLocal$Values.getAfterMiss(ThreadLocal.java:429)
  at java.lang.ThreadLocal.get(ThreadLocal.java:66)

Nessa linha eu estava tentando fazer um new DaoConfigArraye aquela classe tinha a seguinte linha:

// copyOf is only supported in Java >= 1.6
doArray = Arrays.copyOf(daoArray, newLength);

O que tornou tudo ainda mais complicado é que a linha 71 estava apontando para uma ThreadLocalinicialização que eu pensei ser a razão do problema inicialmente.

private static final ThreadLocal<DaoConfigArray> daoConfigLevelLocal
    = new ThreadLocal<DaoConfigArray>() {
    @Override
    protected DaoConfigArray initialValue() {
        return new DaoConfigArray();
    }
};

Tive que remover os projetos dependentes e, em vez disso, compilar os projetos dependentes são jar's e incluí-los na pasta libs.

Tenho certeza de que minha causa foi diferente da sua, mas como este é um dos principais acessos ao pesquisar "Android java.lang.VerifyError", pensei em registrá-lo aqui para a posteridade.

Tive algumas aulas ao longo das linhas de:

public class A { ... }
public class B extends A { ... }
public class C extends A { ... }

E um método que fez:

A[] result = null;
if (something)
    result = new B[cursor.getCount()];
else
    result = new C[cursor.getCount()];

// Fill result
...

Contanto que esse código estivesse presente no arquivo, eu obteria um VerifyError na primeira vez que a classe contendo esse método fosse carregada. Dividi-lo em dois métodos separados (um que lidava apenas com B's e outro que lidava apenas com C) corrigiu o problema.

No meu caso, esse erro ocorre porque meu serviço google-play não é o mais recente .

Se o seu projeto não suportar alguma classe no .jar, esse erro ocorrerá (por exemplo, ImageView.setLayerType, AdvertisingIdClient, etc.).

Acabei de identificar outra situação em que isso ocorre, não só devido a libs não dx 'ed. Eu tenho uma AsyncTask com um mehtod doInBackground muito longo. Por alguma razão, este método com mais de 145 linhas começou a quebrar. Aconteceu em um aplicativo 2.3. Quando eu apenas encapsulei algumas partes em métodos, funcionou bem.

Portanto, para aqueles que não conseguiram encontrar a classe que não foi corrigida corretamente , tente reduzir a duração do seu método.

Para mim, o problema acabou sendo que eu estava usando a cláusula multi-catch em algum lugar da classe que é um recurso do Java 7 (e API 19+). Portanto, ele travaria VerifyErrorem todos os dispositivos anteriores a 19.

Para mim, estava em correlação entre compileSdkVersion e buildToolsVersion. Eu tinha:

compileSdkVersion 21
buildToolsVersion '19.1.0'

Eu mudei para:

compileSdkVersion 21
buildToolsVersion '21.1.2'

Para mim, é o problema de compileSdkVersion. Quando usei a API de nível 21 em um aplicativo Android específico ( https://github.com/android10/Android-AOPExample ):

compileSdkVersion 21

o java.lang.verifyerror aconteceu. Então eu mudei o compileSdkVersion para 19

compileSdkVersion 19

Funcionou bem. Acho que pode ser o problema do SDK buildTools, e parece OK quando o nível de API <21.