Fresco: java.lang.UnsatisfiedLinkError tidak dapat menemukan DSO untuk dimuat: libimagepipeline.so

Dibuat pada 23 Mar 2018 · 9Komentar · Sumber: facebook/fresco

Informasi:

Versi lukisan dinding
Versi platform: Vivo Android 5.1.1, CPU: arm64-v8a

tidak dapat menemukan DSO untuk dimuat: libimagepipeline.so
com.facebook.soloader.SoLoader.void doLoadLibraryBySoName(java.lang.String,int,android.os.StrictMode$ThreadPolicy)...
23-03 19:21:55.955 17814 17931 E art : dlopen("/data/data/xxx/lib-main/libimagepipeline.so", RTLD_LAZY) gagal: dlopen gagal: "/data/data/xxx/lib-main /libimagepipeline.so" adalah 64-bit, bukan 32-bit
23-03 19:21:55.955 17814 17931 E SoLoader: Tidak dapat memuat: libimagepipeline.so

detail

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 gratis(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

Sumber

jyh149129

Komentar yang paling membantu

persetan reaksinya

StoneBang pada 23 Agu 2018

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

Semua 9 komentar

Mungkin duplikat dari https://github.com/facebook/fresco/issues/2049.

gengjiawen pada 24 Mar 2018

Ya, ini tampaknya merupakan duplikat dari #2049 (terutama https://github.com/facebook/fresco/issues/2049#issuecomment-367235216). @jyh149129 , saya menutup masalah di sini untuk memfokuskan diskusi di sana :)

Terima kasih @gengjiawen!

lambdapioneer pada 26 Mar 2018

persetan reaksinya

StoneBang pada 23 Agu 2018

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

Dimana solusinya? Saya menghadapi masalah dalam ketergantungan Fresco versi 1.13.0. Tolong bantu saya.

hardapps1692 pada 13 Jun 2019

Saya pikir saya menemukan mengapa bug ini terjadi, karena cpu_abi dari /data/data/yourpackage/lib dan /data/data/yourpackage/lib-main berbeda.
Dan mengapa berbeda? karena ExtractFromZipSoSource.ensureDsos() memiliki cacat.
cacat apa? Ada asumsi bahwa OS Android mengira Anda adalah aplikasi 64-bit ketika Anda memiliki perpustakaan 32-bit dan 64-bit. Tapi, aturan itu dilanggar pada OPPO R7sm (Android 5.1.1 ColorOS: V3.0_170510_beta).

Saya telah memperbaiki bug pada OPPO saya dengan memodifikasi kode, saya akan membuat permintaan tarik nanti, berharap dapat membantu teman-teman.

artemisia pada 27 Jun 2019

👍2

Luar biasa, terima kasih telah menyelidiki @artemisia!

oprisnik pada 27 Jun 2019

@artemisia Ingin melihat PR Anda！Bug ini sangat membingungkan saya...

sususweet pada 28 Jun 2019

Maaf bahasa Inggrisku buruk.

Perangkat: Perangkat Seluler: OPPC R7sm (AndroLinkid 5.1.1)
Temuan:
Ketika ada armeabi-v7a nad arm64-v8a di apk, umumnya dimuat arm64-v8a. Tapi OPPO R7sm dimuat armeabi-v7a.

Saya memeriksa data jalur/aplikasi//lib/. Temukan adalah lengan, bukan arm64. Umumnya harus arm64

Saat init soloader, akan unzip data/app// .apk. /lib-main.Alur ini akan memeriksa dukungan perangkat abi(ZipUnpacker.ensureDsos() pada ExtractFromZipSoSource.java),dan cek data/aplikasi//lib/lengan/ .so dan */.so dari file apk (ApkUnpacker.shouldExtract() pada ApkSoSource.java).
File tidak sama. akan menyalin ke data/data//lib-main.

Get supportAbis adalah ["arm64-v8a", "armeabi-v7a", "armeabi"]. Konfirmasikan file *.so secara berurutan.
Tetapi data/app//lib/ ada di OPPC R7sm, jadi selalu salin file os arm64-v8a ke data/data//lib-main.

Mengarah ke *.so adalah masalah 64-bit, bukan 32-bit.

solusi saya

Ubah perpustakaan SoLoader. Tambahkan cek data/aplikasi//lib/ adalah lengan atau arm64.

Mengajukan:
EkstrakDariZipSoSource.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());
    ...