Fresco: java.lang.UnsatisfiedLinkError não conseguiu encontrar o DSO para carregar: libimagepipeline.so

Criado em 23 mar. 2018 · 9Comentários · Fonte: facebook/fresco

Info:

Versão Fresco
Versão da plataforma: Vivo Android 5.1.1, CPU: arm64-v8a

não foi possível encontrar DSO para carregar: libimagepipeline.so
com.facebook.soloader.SoLoader.void doLoadLibraryBySoName (java.lang.String, int, android.os.StrictMode $ ThreadPolicy) ...
03-23 19: 21: 55.955 17814 17931 E art: dlopen ("/ data / data / xxx / lib-main / libimagepipeline.so", RTLD_LAZY) falhou: dlopen falhou: "/ data / data / xxx / lib-main /libimagepipeline.so "é de 64 bits em vez de 32 bits
03-23 19: 21: 55.955 17814 17931 E SoLoader: Não foi possível carregar: libimagepipeline.so

detalhe

com.facebook.soloader.SoLoader.void doLoadLibraryBySoName (java.lang.String, int, android.os.StrictMode $ ThreadPolicy) (SoLoader.java:522)
com.facebook.soloader.SoLoader.void loadLibraryBySoName (java.lang.String, java.lang.String, java.lang.String, int, android.os.StrictMode $ ThreadPolicy) (SoLoader.java:420)
com.facebook.soloader.SoLoader.void loadLibrary (java.lang.String, int) (SoLoader.java:370)
com.facebook.soloader.SoLoader.void loadLibrary (java.lang.String) (SoLoader.java:335)
com.facebook.imagepipeline.nativecode.ImagePipelineNativeLoader.void load () (ImagePipelineNativeLoader.java:42)
com.facebook.imagepipeline.memory.NativeMemoryChunk.void() (NativeMemoryChunk.java:33)
com.facebook.imagepipeline.memory.NativeMemoryChunkPool.com.facebook.imagepipeline.memory.NativeMemoryChunk alloc (int) (NativeMemoryChunkPool.java:58)
com.facebook.imagepipeline.memory.NativeMemoryChunkPool.void free (java.lang.Object) (NativeMemoryChunkPool.java:20)

_parent _ ## 1 ## _ parent_

_child _ ## java.lang.Object alloc (int) ## _ child_

com.facebook.imagepipeline.memory.BasePool.java.lang.Object get (int) (BasePool.java:257)
com.facebook.imagepipeline.memory.NativePooledByteBufferOutputStream.void(com.facebook.imagepipeline.memory.NativeMemoryChunkPool, int) (NativePooledByteBufferOutputStream.java:51)
com.facebook.imagepipeline.memory.NativePooledByteBufferFactory.com.facebook.imagepipeline.memory.NativePooledByteBuffer newByteBuffer (java.io.InputStream, int) (NativePooledByteBufferFactory.java:98)
com.facebook.imagepipeline.memory.NativePooledByteBufferFactory.com.facebook.common.memory.PooledByteBufferOutputStream newOutputStream (int) (NativePooledByteBufferFactory.java:26)

_parent _ ## 4 ## _ parent_

_child _ ## com.facebook.common.memory.PooledByteBufferOutputStream newOutputStream () ## _ child_

_child _ ## com.facebook.common.memory.PooledByteBuffer newByteBuffer (java.io.InputStream, int) ## _ child_

_child _ ## com.facebook.common.memory.PooledByteBuffer newByteBuffer (byte []) ## _ child_

_child _ ## com.facebook.common.memory.PooledByteBuffer newByteBuffer (java.io.InputStream) ## _ child_

com.facebook.imagepipeline.producers.LocalFetchProducer.com.facebook.imagepipeline.image.EncodedImage getByteBufferBackedEncodedImage (java.io.InputStream, int) (LocalFetchProducer.java:89)

_parent _ ## 2 ## _ parent_

_child _ ## com.facebook.imagepipeline.image.EncodedImage getEncodedImage (com.facebook.imagepipeline.request.ImageRequest) ## _ child_

_child _ ## java.lang.String getProducerName () ## _ child_

com.facebook.imagepipeline.producers.LocalFetchProducer.com.facebook.imagepipeline.image.EncodedImage getEncodedImage (java.io.InputStream, int) (LocalFetchProducer.java:101)
com.facebook.imagepipeline.producers.LocalFileFetchProducer.com.facebook.imagepipeline.image.EncodedImage getEncodedImage (com.facebook.imagepipeline.request.ImageRequest) (LocalFileFetchProducer.java:34)
com.facebook.imagepipeline.producers.LocalFetchProducer $ 1.com.facebook.imagepipeline.image.EncodedImage getResult () (LocalFetchProducer.java:54)
com.facebook.imagepipeline.producers.LocalFetchProducer $ 1.java.lang.Object getResult () (LocalFetchProducer.java:50)
com.facebook.common.executors.StatefulRunnable.void run () (StatefulRunnable.java:45)
java.util.concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor.java:1112)
java.util.concurrent.ThreadPoolExecutor $ Worker.run (ThreadPoolExecutor.java:587)
com.facebook.imagepipeline.core.PriorityThreadFactory $ 1.void run () (PriorityThreadFactory.java:53)
java.lang.Thread.run (Thread.java:818)

duplicate

Fonte

jyh149129

Comentários muito úteis

foda-se a reação

StoneBang em 23 ago. 2018

👍62 😄15 👀5 😕2 ❤1 👎1

Todos 9 comentários

Possivelmente duplicado de https://github.com/facebook/fresco/issues/2049.

gengjiawen em 24 mar. 2018

Sim, parece ser uma duplicata de # 2049 (especialmente https://github.com/facebook/fresco/issues/2049#issuecomment-367235216). @ jyh149129 , estou encerrando o problema aqui para focar a discussão ali :)

Obrigado @gengjiawen!

lambdapioneer em 26 mar. 2018

foda-se a reação

StoneBang em 23 ago. 2018

👍62 😄15 👀5 😕2 ❤1 👎1

Onde está a solução? Estou enfrentando problemas na versão 1.13.0 da dependência do Fresco. Por favor, me ajude.

hardapps1692 em 13 jun. 2019

Acho que descobri por que esse bug aconteceu, porque o cpu_abi de / data / data / yourpackage / lib e / data / data / yourpackage / lib-main é diferente.
E por que é diferente? porque ExtractFromZipSoSource.ensureDsos () tinha um defeito.
Qual defeito? Supunha-se que o sistema operacional Android pensava que você era um aplicativo de 64 bits quando tinha bibliotecas de 32 e 64 bits. Mas, a regra foi quebrada no OPPO R7sm (Android 5.1.1 ColorOS: V3.0_170510_beta).

Corrigi o bug no meu OPPO modificando o código, farei uma solicitação de pull mais tarde, esperando ajudar seus rapazes.

artemisia em 27 jun. 2019

👍2

Incrível, obrigado por investigar @artemisia!

oprisnik em 27 jun. 2019

@artemisia Gostaria de ver sua RP！ Esse bug me confunde muito ...

sususweet em 28 jun. 2019

Desculpe o meu Inglês é ruim.

Dispositivo: Dispositivo móvel: OPPC R7sm (AndroLinkid 5.1.1)
Resultados:
Quando existe armeabi-v7a nad arm64-v8a no apk, geralmente carregado arm64-v8a. Mas OPPO R7sm é carregado armeabi-v7a.

Eu verifico o caminho de dados / app // lib /. Find é arm, não arm64. Geralmente deve ser arm64

Quando init soloader, vai descompactar data / app // .apk. / lib-main.Este fluxo verificará o dispositivo de suporte abi (ZipUnpacker.ensureDsos () em ExtractFromZipSoSource.java),e verificar dados / app // lib / arm / .so e * /. so do arquivo apk (ApkUnpacker.shouldExtract () em ApkSoSource.java).
Os arquivos não são os mesmos. irá copiar para dados / dados // lib-main.

O get supportedAbis é ["arm64-v8a", "armeabi-v7a", "armeabi"]. Confirme o arquivo * .so sequencialmente.
Mas data / app // lib / is arm no OPPC R7sm, então sempre copie arm64-v8a o arquivo os para data / data // lib-main.

Conduzir para * .so é 64 bits em vez de problema de 32 bits.

Minha solução:

Modifique a biblioteca SoLoader. Adicionar dados de verificação / app // lib / é arm ou arm64.

Arquivo:
ExtractFromZipSoSource.java

    ...
    final ZipDso[] ensureDsos() {
      if (mDsos == null) {
        Set<String> librariesAbiSet = new LinkedHashSet<>();
        HashMap<String, ZipDso> providedLibraries = new HashMap<>();
        Pattern zipSearchPattern = Pattern.compile(mZipSearchPattern);
        String[] supportedAbis = SysUtil.getSupportedAbis();
        Enumeration<? extends ZipEntry> entries = mZipFile.entries();

+        // Fixed couldn't find DSO to load:  "xxx.os"  is 64-bit instead of 32-bit
+       File sysLibPath =  new File(mContext.getApplicationInfo().nativeLibraryDir);
+       String sysLibAbi = sysLibPath.getPath().substring(sysLibPath.getPath().lastIndexOf("/")+1);
+       if(sysLibAbi.equalsIgnoreCase("arm")) {
+         // sys lib is load armeabi-v7a, this exception case
+         ArrayList<String> newSupportedAbis = new ArrayList();
+         for(String abi : supportedAbis) {
+           if(abi.equalsIgnoreCase("arm64-v8a")) {
+               //skip arm64-v8a
+               continue;
+           }
+
+           newSupportedAbis.add(abi);
+         }
+
+         supportedAbis = newSupportedAbis.toArray(new String[newSupportedAbis.size()]);
+       }


        while (entries.hasMoreElements()) {
          ZipEntry entry = entries.nextElement();
          Matcher m = zipSearchPattern.matcher(entry.getName());
    ...

YS-WEI em 18 jul. 2019

foda-se a reação

Bem-vindo Flutter

spvalencia em 17 out. 2019

Esta página foi útil?

0 / 5 - 0 avaliações

Questões relacionadas

Fresco não suporta opções de redimensionamento como picasso

amodkanthe · 3Comentários

Solicitado: Lcom / facebook / imagepipeline / nativecode / Bitmaps; .nativeCopyBitmap: (Landroid / graphics / Bitmap; ILandroid / graphics / Bitmap; II) V

836154942 · 3Comentários

A rotação para a imagem do recurso não está funcionando

cococool · 4Comentários

Resposta de erro HTTP ao carregar resultados de imagem em conexão perdida

stephen-workpop · 4Comentários

afresco versão "0.10.0" não pode exibir gif?

liubaoyua · 3Comentários