Solução de erro UnsatisfiedLinkError do Android Studio

1 ： 当 程序 报错 ：
Causado por: java.lang.UnsatisfiedLinkError: com.android.tools.fd.runtime.IncrementalClassLoader $ DelegateClassLoader [DexPathList

A maior parte da razão é que o arquivo so não é carregado normalmente

2: Descubra o motivo:

Primeiro julgue se você se esqueceu de copiar o arquivo so correspondente para o diretório JNI correspondente

Descubra a arquitetura da CPU do telefone móvel, vá para o diretório JNI correspondente para ver se há um arquivo so correspondente

3: Solução:

1) Copie o arquivo so correspondente para o diretório de arquitetura JNI correspondente

2) Se houver apenas alguns arquivos de algumas dessas arquiteturas, mas a arquitetura do telefone celular não pertencer a elas, você pode definir isso no projeto:

android {
 defaultConfig {
    ndk {
     // 设置支持的 SO 库构架，注意这里要根据你的实际情况来设置           abiFilters 'armeabi'// 'armeabi-v7a', 'arm64-v8a', 'x86', 'x86_64', 'mips', 'mips64' 
      }
   }
} 

Se o Android Studio exibir as seguintes informações depois de adicionar "abiFilter":
NDK Integration IS obsoleto no plug-in Considere tentar em The Current at The Experimental novo plug-in.
Adicione o arquivo gradle.properties no diretório raiz do projeto:
android.useDeprecatedNdk = to true
Observe que: Este método corresponde a um telefone celular com arquitetura de 64 bits, mas apenas de 32 bits, então os arquivos são mais eficazes. Para conhecer a arquitetura, consulte as instruções do Baidu

Telefones celulares de 64 bits (arm64-v8a) podem ser executados em 32 bits (armeabi armeabi-v7a), portanto, arquivos

(Dois) android studio carrega o arquivo so e erros. android java.lang.UnsatisfiedLinkError: Análise e soluções

A biblioteca .so é colocada no diretório de arquitetura da CPU correspondente em libs / do módulo principal, como libs / armeabi.
No arquivo build.gradle do módulo principal, adicione a tag android:

sourceSets {
    main {
        jniLibs.srcDirs = ['libs']
    }
}

Então, há um erro:
android java.lang.UnsatisfiedLinkError: análise e soluções "

Um, o jni ainda não foi compilado, ele é usado durante a compilação

Isso pode ser dividido em dois casos: o
　　primeiro é linkerror insatisfeito: nome da dll. Explique que a dll não foi colocada na posição adequada. Para o desenvolvimento do Android, geralmente colocamos isso no diretório libs, mas esse erro ainda ocorre. A causa raiz é que a função system.loadlibrary carregará o assim que você especificar. Todos os símbolos no so que precisam ser vinculados devem poder ser vinculados. Se um link falhar, o sim inteiro também falhará ao carregar. Verifique cuidadosamente todos os símbolos necessários no so para se certificar de que estão presentes e nas posições corretas.

　　O segundo é linkerror insatisfeito: nome do método. A dll foi carregada com sucesso, mas o nome do método está errado. A solução mais comum e básica para esse erro é comparar cuidadosamente o protótipo de seu método nativo para garantir que ele seja consistente com o protótipo gerado por javah. Para modificar o nome do método nativo no lado java, você deve se lembrar de atualizar o nome da função no lado c / c ++. Esta é a causa mais comum de tais erros.

Em segundo lugar, é que a jni compilou a biblioteca diretamente com outras pessoas, então
você constrói o projeto, coloque loadlibrary () da classe no nome do pacote e no nome da classe loadlibrary (), onde o projeto original para compilar o tempo jni deve ser consistente, porque jni parece basear-se em O nome do pacote java é nomeado, então não há problema em alterá-lo para um nome consistente

(C) O arquivo java.lang.UnsatisfiedLinkError .so do Android Studio falhou ao carregar soluções para
o problema: java.lang.UnsatisfiedLinkError: dalvik.system.PathClassLoader [DexPathList [[ arquivo zip "/data/app/com.example.demozd- 1 / base.apk "], nativeLibraryDirectories = [/ vendor / lib64, / system / lib64]]] não conseguiu encontrar" libmsc.so "
Obviamente, isso foi causado por não ser capaz de encontrar o arquivo .so quando o programa estava corrida.

Solução:

1. Certifique-se de que haja um arquivo .so em seu projeto. Se o erro for igual ao meu, você não consegue encontrar lib64 Barabara, você também deve verificar se há arm64-v8a em seu projeto. Caso contrário, crie um e, em seguida, copie o arquivo .so em armeabi;
2. Se você colocar todas as pastas .so em libs, será necessário adicionar o seguinte código nas chaves do Android em seu arquivo build.gradle:

sourceSets {  
        main {  
            jniLibs.srcDirs = ['libs']  
        }  
    }  

3. Se todas as suas pastas .so estiverem em jniLibs, certifique-se de que sua pasta jniLibs esteja em src / main / path, não no mesmo nível de src.

Vamos fazer uma explicação a partir da carta circular da biblioteca de terceiros

Algumas bibliotecas de terceiros são apenas um pacote jar simples, mas algumas são desenvolvidas usando jni, portanto, incluirão o arquivo de biblioteca so. Se não houver mensagem neste momento, encontraremos um erro: java.lang.UnsatisfiedLinkError;
por usando o SDK da carta de toque Quando esse erro ocorrer, compartilhe aqui a causa do problema e a solução;

Preciso explicar as informações relacionadas aqui
. O tipo de conjunto de instruções fornecido por hyphenatechatsdk fornece apenas armeabi-v7a, arm64-v8a e x86;
armeabi e armeabi-v7a são conjuntos de instruções semelhantes, v7a é um conjunto de instruções aprimorado, velocidade operacional, eficiência São todas instruções de 32 bits e compatíveis; arm64-v8a corresponde ao conjunto de instruções arm64-bit;
a estratégia arm64-bit é diferente de intel IA32: as instruções Intel64-bit são compatíveis com instruções intel32-bit e programas compilados com intel32- as instruções de bit podem ser compiladas diretamente Ele é executado em uma máquina intel64-bit; mas o arm não é, arm64-bit e arm32-bit são sistemas de instrução independentes e não são compatíveis; a razão para o design do arm é porque ele é executado em sistemas embarcados , os indicadores de design tendem a ser mais eficientes e as considerações de consumo de energia; Na verdade, o chip arm64-bit contém o processador de instrução arm64 e o processador de instrução arm32-bit, mas os dois processadores são independentes um do outro;

UnsatisfiedLinkError leva a vários motivos que
afetam as restrições de link: armeabi pode realmente ser executado em máquinas arm64 bits, mas o Google adiciona restrições:

1. Android4.x pode ser executado enquanto puder, então pode ser em armeabi, armeabi-v7a, arm64-v8a, então a localização pode ser muito arbitrária;
2. A partir do Android5.x, a inspeção é mais rigorosa e apenas o so no diretório correspondente ao modelo do chip será instalado no telefone;
   por exemplo: a
   estrutura do diretório no ambiente de desenvolvimento é a seguinte:
   libs / armeabi: libhyphenate .so libhyphenate_av.so
   libs / armeabi-v7a:
   O conjunto de instruções correspondente ao telefone móvel libmediadata.so é armeabi-v7a e, então, apenas libmediadata.so é instalado no telefone móvel;
3. No Android6.x, a inspeção é mais rigorosa. Há uma regra que foi encontrada no teste anterior, mas não
   tenho certeza agora; libs / armeabi /: libhyphenate.so libhyphenate_av.so
   libs / arm64-v8a (não há tal diretório)
   em máquinas arm64-bit Ele também pode ser executado, mas como desenvolvedor, você geralmente conta com outros pacotes de desenvolvimento, como baiduMap, e também usa outros. Você não pode permitir que todos os desenvolvedores excluam o diretório libs / arm64-v8a ; mas os desenvolvedores podem tentar excluir arm64-v8a, resta apenas armeabi, para que o pacote de instalação seja pequeno e possa ser executado em várias plataformas;
   a consideração do Google é a taxa de execução e uma experiência do usuário mais suave. Como desenvolvedor e provedor de serviços, esperamos que o apk seja o menor possível para execução. O requisito de velocidade não é alto;
4. Armeabi e armeabi-v7a são intercambiáveis. Poucos telefones celulares no mercado agora têm armeabi. Eles são basicamente armeabi-v7a ou arm64-bit máquinas high-end.
5. Verifique o modelo do chip do telefone móvel: cat / proc / cpuinfo, dê uma olhada nas informações impressas e você pode ver se o conjunto de instruções do telefone móvel é de 32 bits ou 64 bits.
6. O diretório x86 geralmente corresponde a uma máquina virtual. Muitos desenvolvedores gostam de desenvolver e depurar no genymotion. Isso corresponde a 86. x86 é o mesmo que o intel IA32 mencionado acima, portanto, apenas 32 bits é fornecido e também pode ser usado em máquinas x86-64 bits. Execute em
7. Nosso também depende de libsqlite.so, mas como este pacote nunca mudou, ele usa o / system / lib padrão fornecido pelo sistema, que pode ser executado em plataformas Android 6.x e inferiores, e Android 7.x implementa segurança mais rígida Verifique, é proibido usar o conteúdo do catálogo do sistema, então se você quiser usar Android7.x ou superior, você precisa copiar o libsqlite.so do catálogo do sistema e colocá-lo no diretório de instrução correspondente do seu aplicativo, porque não há modelos no mercado Android7.x., Portanto, não está sendo considerado;
8. Telefones celulares com conjunto de instruções mips são raros. Ouvi dizer que a Lenovo tem um, mas nunca vi;
9. libs / armeabi / libhyphenate.so e libs.without.audio/armeabi/libhyphenate.so são diferentes, libs / armeabi / libhyphenate.so dependerá de libs / armeabi / libhyphenate_av.so, se não for encontrado, ele relatará java.lang .InsatisfiedLinkError;
10. Há outro ponto que é mais fácil de ignorar. Agora nossos projetos geralmente apresentam várias bibliotecas de terceiros. O sexto ponto também menciona o uso de baiduMap, ou seja, quando um projeto apresenta várias bibliotecas, diferentes bibliotecas têm pastas diferentes para que, quando uma do suporte é relativamente pequeno, mas outra comparação inteira, ocorreria tal erro, a solução não é suportada então a pasta para excluir
    Por exemplo:
    conjunto de instruções com suporte carta de anel arm64-v8a, armeabi-v7a, x86
    mapa Baidu suporta o conjunto de instruções arm64-v8a, armeabi, armeabi-v7a, x86, x86_64, mips, mips64
    se você quiser executar em todos os dispositivos, você precisa excluir x86_64, mips, mips64; de
    acordo com o anterior Diz-se que você pode manter o armeabi e pastas armeabi-v7a e, em seguida, copie o arquivo so em armeabi-v7a para armeabi.

Finalmente, contanto que você observe cuidadosamente o prompt de log do ide, é fácil de resolver.