Fresco: java.lang.UnsatisfiedLinkError konnte DSO zum Laden nicht finden: libimagepipeline.so

Erstellt am 23. März 2018  ·  9Kommentare  ·  Quelle: facebook/fresco

Die Info:

  • Fresko- Version: 1.8.1
  • Plattformversion: Vivo Android 5.1.1, CPU: arm64-v8a

DSO konnte nicht geladen werden: 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) failed: dlopen failed: "/data/data/xxx/lib-main /libimagepipeline.so" ist 64-Bit statt 32-Bit
03-23 ​​19:21:55.955 17814 17931 E SoLoader: Konnte nicht geladen werden: 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 free(java.lang.Object)(NativeMemoryChunkPool.java:20)

_Eltern_##1##_Eltern_

_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)

_Eltern_##4##_Eltern_

_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)

_Eltern_##2##_Eltern_

_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
Quelle
picture jyh149129

Hilfreichster Kommentar

scheiß auf die reaktion

picture StoneBang am 23. Aug. 2018
👍62 😄15 👀5 😕2 ❤1 👎1

Alle 9 Kommentare

Möglicherweise Duplikat von https://github.com/facebook/fresco/issues/2049.

gengjiawen picture gengjiawen am 24. März 2018

Ja, dies scheint ein Duplikat von #2049 zu sein (insbesondere https://github.com/facebook/fresco/issues/2049#issuecomment-367235216). @ jyh149129 , ich schließe das Thema hier, um die Diskussion dort zu fokussieren :)

Danke @gengjiawen!

lambdapioneer picture lambdapioneer am 26. März 2018

scheiß auf die reaktion

StoneBang picture StoneBang am 23. Aug. 2018
👍62 😄15 👀5 😕2 ❤1 👎1

Wo ist die Lösung? Ich habe ein Problem in Version 1.13.0 der Fresco-Abhängigkeit. Bitte hilf mir.

hardapps1692 picture hardapps1692 am 13. Juni 2019

Ich glaube, ich habe herausgefunden, warum dieser Fehler aufgetreten ist, weil die cpu_abi von /data/data/yourpackage/lib und /data/data/yourpackage/lib-main unterschiedlich sind.
Und warum ist es anders? weil ExtractFromZipSoSource.ensureDsos() einen Defekt hatte.
Welcher Defekt? Es wurde angenommen, dass das Android-Betriebssystem Sie für eine 64-Bit-App hält, wenn Sie sowohl 32-Bit- als auch 64-Bit-Bibliotheken haben. Auf dem OPPO R7sm (Android 5.1.1 ColorOS: V3.0_170510_beta) wurde die Regel jedoch gebrochen.

Ich habe den Fehler in meinem OPPO behoben, indem ich den Code geändert habe. Ich werde später eine Pull-Anfrage stellen, in der Erwartung, Ihren Jungs zu helfen.

artemisia picture artemisia am 27. Juni 2019
👍2

Super, danke für die Untersuchung von @artemisia!

oprisnik picture oprisnik am 27. Juni 2019

@artemisia Ich

sususweet picture sususweet am 28. Juni 2019

Tut mir leid, mein Englisch ist schlecht.

Gerät: Mobilgerät: OPPC R7sm (AndroLinkid 5.1.1)
Ergebnisse:
Wenn armeabi-v7a und arm64-v8a in apk vorhanden ist, wird im Allgemeinen arm64-v8a geladen. Aber OPPO R7sm ist armeabi-v7a geladen.

Ich überprüfe Pfaddaten/App//lib/. Find ist arm, ist nicht arm64. Im Allgemeinen sollte arm64 sein

Wenn der Soloader initiert wird, werden Daten/App/ entpackt/ .apk. /lib-main.Dieser Flow überprüft die Geräteunterstützung abi(ZipUnpacker.ensureDsos() auf ExtractFromZipSoSource.java),und Daten/App/ überprüfen/lib/arm/ .so und */.so der APK-Datei (ApkUnpacker.shouldExtract() auf ApkSoSource.java).
Die Dateien sind nicht gleich. wird nach data/data/ kopieren/lib-main.

Das unterstützte Abis ist ["arm64-v8a", "armeabi-v7a", "armeabi"]. Bestätigen Sie die *.so-Datei nacheinander.
Aber data/app//lib/ ist auf OPPC R7sm arm, also kopieren Sie immer arm64-v8a die os-Datei nach data/data//lib-main.

Lead to *.so ist 64-Bit- statt 32-Bit-Ausgabe.

Meine Lösung:

Ändern Sie die SoLoader-Bibliothek. Scheckdaten/App/ hinzufügen/lib/ ist arm oder arm64.

Datei:
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 picture YS-WEI am 18. Juli 2019

scheiß auf die reaktion

Willkommensflattern

spvalencia picture spvalencia am 17. Okt. 2019
War diese Seite hilfreich?
0 / 5 - 0 Bewertungen

Verwandte Themen

836154942 picture 836154942  ·  3Kommentare
rhettor picture rhettor  ·  3Kommentare
hbzhzw picture hbzhzw  ·  3Kommentare
hanhmh1203 picture hanhmh1203  ·  4Kommentare
qiiyue picture qiiyue  ·  4Kommentare