Fresco: Lors de la création via App Bundle, Fresco ne parvient pas à trouver "libimagepipeline.so"

Créé le 7 déc. 2018  ·  21Commentaires  ·  Source: facebook/fresco

La description

Lors du lancement d'une activité qui utilise Fresco, qui a été générée via Android App Bundle , il ne parvient pas à trouver "libimagepipeline.so" et plante l'application.

la reproduction

  1. Créer un exemple d'application qui utilise Fresco
  2. Générer un Bundle signé
  3. À l'aide de Bundle Tool, créez les APK à partir du Bundle
  4. À l'aide de Bundle Tool, installez l'APK sur votre appareil
  5. Accédez à Activité où Fresco est initialisé
  6. Observer le crash

Solution

Au départ, je pensais que cela pouvait être un problème avec minify, R8 ou Proguard, mais je les ai tous désactivés et j'ai toujours observé le même résultat lors de la création via App Bundle.

J'ai testé d'autres composants de mon application qui utilisent également des bibliothèques natives, mais ils fonctionnent tous comme prévu, uniquement avec Fresco qui a du mal à charger le binaire respectif.

Une solution temporaire, mais pas idéale, que j'ai trouvée consiste à désactiver le fractionnement des APK par abi à l'aide de la configuration suivante, mais l'inclusion de tous les fichiers binaires entraîne une taille d'APK considérablement plus grande.

android {
    // Rest of your configuration here

    bundle {
        abi {
            enableSplit false
        }
    }
}

Information additionnelle

  • Version fresque : 1.10.0
  • Version de la plate-forme : Samsung SM-G955F, Android 8.0.0
bug help wanted

Commentaire le plus utile

J'ai découvert un problème dans la bibliothèque SoLoader utilisée par Fresco. J'ai préparé les relations publiques avec un correctif : facebook/soloader#26
Ce correctif permet à la fresque de fonctionner correctement avec l'app bundle.
J'ai publié la version corrigée de SoLoader lib. Vous pouvez l'utiliser dans votre projet si vous ne pouvez pas attendre que PR soit fusionné.

repositories {
    maven {
        url  "https://dl.bintray.com/nnesterov/maven" 
    }
}

compile('com.facebook.fresco:fresco:1.10.0') {
    exclude group: 'com.facebook.soloader', module: 'soloader'
}
compile("com.avito.android:patched-soloader:0.1.0")

Tous les 21 commentaires

Votre message d'erreur ressemble-t-il à celui-ci ? #2049

Oui, en gros. Cependant, cette question, bien que liée, je pense qu'elle se concentre davantage sur la
manque de prise en charge d'Android App Bundle dans Fresco ou SoLoader et
diviser les binaires de cette façon.

Je peux me tromper, mais ce problème est reproductible sur tous les appareils que j'ai
testé, pas seulement des marques sélectionnées.

Et selon les guides d'expédition Fresco, il n'y a pas de note sur le cas d'utilisation de
expédition via Android App Bundles, et nous ne pouvons pas utiliser la clé splits comme quand
vous utilisez bundle la clé splits est ignorée.

Le mardi 11 décembre 2018, 06:40 KimiChiu, [email protected] a écrit :

Votre message d'erreur ressemble-t-il à celui-ci ? #2049
https://github.com/facebook/fresco/issues/2049

-
Vous recevez ceci parce que vous avez créé le fil.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/facebook/fresco/issues/2253#issuecomment-446089907 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/ABUQnQ4cZ-sWkG5b72Ea81wiQjS02yjlks5u31NxgaJpZM4ZIsuf
.

Salut @icerfish ,

Merci d'avoir déposé ce problème avec tous les détails requis (peut-être ajouter une pâte de l'erreur si vous avez le temps). Je peux imaginer que Fresco pourrait ne pas prendre entièrement en charge les bundles d'applications et je ne pense pas que nous ayons déjà testé l'interaction.

Je vais marquer cela comme un "bug" et "aide recherchée" en espérant que c'est quelque chose avec lequel la communauté open source peut nous aider.

Salut @lambdapioneer ,

Voici la trace de la pile :

FATAL EXCEPTION: FrescoIoBoundExecutor-8 Process: com.gobuzzvault.android, PID: 17499 java.lang.NoClassDefFoundError: com.facebook.imagepipeline.memory.NativeMemoryChunk at com.facebook.imagepipeline.memory.NativeMemoryChunkPool.alloc(NativeMemoryChunkPool.java:25) at com.facebook.imagepipeline.memory.NativeMemoryChunkPool.alloc(NativeMemoryChunkPool.java:13) at com.facebook.imagepipeline.memory.BasePool.get(BasePool.java:267) at com.facebook.imagepipeline.memory.MemoryPooledByteBufferOutputStream.<init>(MemoryPooledByteBufferOutputStream.java:51) at com.facebook.imagepipeline.memory.MemoryPooledByteBufferFactory.newByteBuffer(MemoryPooledByteBufferFactory.java:73) at com.facebook.imagepipeline.memory.MemoryPooledByteBufferFactory.newByteBuffer(MemoryPooledByteBufferFactory.java:24) at com.facebook.imagepipeline.producers.LocalFetchProducer.getByteBufferBackedEncodedImage(LocalFetchProducer.java:87) at com.facebook.imagepipeline.producers.LocalFetchProducer.getEncodedImage(LocalFetchProducer.java:99) at com.facebook.imagepipeline.producers.LocalContentUriFetchProducer.getCameraImage(LocalContentUriFetchProducer.java:100) at com.facebook.imagepipeline.producers.LocalContentUriFetchProducer.getEncodedImage(LocalContentUriFetchProducer.java:76) at com.facebook.imagepipeline.producers.LocalFetchProducer$1.getResult(LocalFetchProducer.java:52) at com.facebook.imagepipeline.producers.LocalFetchProducer$1.getResult(LocalFetchProducer.java:48) at com.facebook.common.executors.StatefulRunnable.run(StatefulRunnable.java:43) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1162) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:636) at com.facebook.imagepipeline.core.PriorityThreadFactory$1.run(PriorityThreadFactory.java:51) at java.lang.Thread.run(Thread.java:764) Caused by: java.lang.UnsatisfiedLinkError: couldn't find DSO to load: libimagepipeline.so at com.facebook.soloader.SoLoader.doLoadLibraryBySoName(SoLoader.java:703) at com.facebook.soloader.SoLoader.loadLibraryBySoName(SoLoader.java:564) at com.facebook.soloader.SoLoader.loadLibrary(SoLoader.java:500) at com.facebook.soloader.SoLoader.loadLibrary(SoLoader.java:455) at com.facebook.imagepipeline.nativecode.ImagePipelineNativeLoader.load(ImagePipelineNativeLoader.java:40) at com.facebook.imagepipeline.memory.NativeMemoryChunk.<clinit>(NativeMemoryChunk.java:31) at com.facebook.imagepipeline.memory.NativeMemoryChunkPool.alloc(NativeMemoryChunkPool.java:25) at com.facebook.imagepipeline.memory.NativeMemoryChunkPool.alloc(NativeMemoryChunkPool.java:13) at com.facebook.imagepipeline.memory.BasePool.get(BasePool.java:267) at com.facebook.imagepipeline.memory.MemoryPooledByteBufferOutputStream.<init>(MemoryPooledByteBufferOutputStream.java:51) at com.facebook.imagepipeline.memory.MemoryPooledByteBufferFactory.newByteBuffer(MemoryPooledByteBufferFactory.java:73) at com.facebook.imagepipeline.memory.MemoryPooledByteBufferFactory.newByteBuffer(MemoryPooledByteBufferFactory.java:24) at com.facebook.imagepipeline.producers.LocalFetchProducer.getByteBufferBackedEncodedImage(LocalFetchProducer.java:87) at com.facebook.imagepipeline.producers.LocalFetchProducer.getEncodedImage(LocalFetchProducer.java:99) at com.facebook.imagepipeline.producers.LocalContentUriThumbnailFetchProducer.getThumbnail(LocalContentUriThumbnailFetchProducer.java:135) at com.facebook.imagepipeline.producers.LocalContentUriThumbnailFetchProducer.getCameraImage(LocalContentUriThumbnailFetchProducer.java:100) at com.facebook.imagepipeline.producers.LocalContentUriThumbnailFetchProducer.getEncodedImage(LocalContentUriThumbnailFetchProducer.java:75) at com.facebook.imagepipeline.producers.LocalFetchProducer$1.getResult(LocalFetchProducer.java:52)  at com.facebook.imagepipeline.producers.LocalFetchProducer$1.getResult(LocalFetchProducer.java:48)  at com.facebook.common.executors.StatefulRunnable.run(StatefulRunnable.java:43)  at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1162)  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:636)  at com.facebook.imagepipeline.core.PriorityThreadFactory$1.run(PriorityThreadFactory.java:51)  at java.lang.Thread.run(Thread.java:764)

Cela ressemble à des problèmes que d'autres ont.

En regardant autour de la base de code, il semble que ce ne soit pas un problème avec Fresco lui-même, mais plutôt avec la bibliothèque SoLoader. Je vais poster le problème sur ce référentiel, et la charge de travail permettant de consacrer du temps à essayer de déterminer quel est le problème exactement.

Salut, j'ai eu le même problème lors de l'utilisation des bundles d'applications, comme décrit dans https://github.com/facebook/fresco/issues/2049#issuecomment -441088387

En utilisant Fresco 1.11 et en définissant .experiment().setNativeCodeDisabled(true) dans ImagePipelineConfig de Fresco, les images statiques fonctionnaient pour moi, mais les GIF se sont écrasés avec une trace de pile différente, qui ressemblait au même problème SoLoader avec une bibliothèque différente. @icerfish , cela peut vous aider si vous n'utilisez pas de GIF.

J'ai découvert un problème dans la bibliothèque SoLoader utilisée par Fresco. J'ai préparé les relations publiques avec un correctif : facebook/soloader#26
Ce correctif permet à la fresque de fonctionner correctement avec l'app bundle.
J'ai publié la version corrigée de SoLoader lib. Vous pouvez l'utiliser dans votre projet si vous ne pouvez pas attendre que PR soit fusionné.

repositories {
    maven {
        url  "https://dl.bintray.com/nnesterov/maven" 
    }
}

compile('com.facebook.fresco:fresco:1.10.0') {
    exclude group: 'com.facebook.soloader', module: 'soloader'
}
compile("com.avito.android:patched-soloader:0.1.0")

La version précédente de patched-soloader ne fonctionnait pas sur les appareils pré-lollipop. Je l'ai corrigé. Utilisation
compile("com.avito.android:patched-soloader:0.1.1")

@nesterov-n merci pour le bon correctif, des progrès pour l'intégrer dans la fresque ?

@nesterov-n je suis également confronté au même problème. s'il vous plaît laissez-moi savoir quand sera-t-il intégré dans la fresque?

Salut @theromis et @sailesh2
Je ne travaille pas sur Facebook (c'est tellement triste). Je ne suis qu'un utilisateur de Fresco mais je ne pouvais pas attendre un correctif. J'ai donc dû le déboguer et le réparer.
Actuellement, j'utilise la version corrigée de soloder lib pour mon projet comme je l'ai décrit dans le commentaire ci-dessus. La version la plus récente est com.avito.android:patched-soloader:0.1.2

Mon PR à soloader lib est en cours de révision, mais le mainteneur de soloader dit qu'il n'y a pas d'estimation de la nouvelle version de soloader lib. Il est donc impossible d'estimer quand Fresco utilisera cette nouvelle version.

Si c'est urgent, vous pouvez utiliser ma version corrigée. Nous avons publié un bundle avec fresque à la production. Fonctionne bien.

Impossible de comprendre pourquoi cette solution de contournement n'est pas encore intégrée à Fresco.

Nous avons débarqué le correctif SoLoader. Nous publierons bientôt une nouvelle version de Fresco une fois la version SoLoader publiée.

@oprisnik quel est l'ETA pour les sorties ? Je comprends que cela nécessite la coordination de 2 équipes, mais au moins un nombre approximatif aiderait de nombreux développeurs à décider s'ils doivent appliquer la solution de contournement ci-dessus ou attendre la sortie.

SoLoader v0.6.0 vient de sortir et j'ai mis à jour la dépendance Fresco (6fc071d1892166d11d1f237f10e2d9bcdf858087). Nous voulons attendre la sortie de Bolts sous licence MIT (#2257). Si cette version prend plus de temps que prévu, nous allons l'ignorer pour le moment et publier sans cela. Dans tous les cas, la nouvelle version devrait sortir dans quelques jours.

Je ne veux pas être ennuyeux, mais la fresque ne devrait-elle pas être libérée ? Il semble que ce problème que vous avez signalé n'a reçu aucune activité depuis un certain temps.

Nous venons de publier la version 1.12.0 qui inclut la version fixe de SoLoader.

essayez d'ajouter proguard

Ne supprimez aucune méthode/classe annotée avec @DoNotStrip

-garder la classe @com.facebook.common.internal.DoNotStrip *
-keepclassmembers class * {
@com.facebook.common.internal.DoNotStrip *;
}

Ne supprimez aucune méthode/classe annotée avec @DoNotOptimize

-gardez la classe @com.facebook.soloader.DoNotOptimize *
-keepclassmembers class * {
@com.facebook.soloader.DoNotOptimize *;
}

Conserver les méthodes natives

-keepclassmembers class * {
originaire de;
}

-ne préviens pas okio. *-ne pas avertir com.squareup.okhttp. *
-ne pas avertir okhttp3. *-ne pas avertir javax.annotation. *
-ne pas avertir com.android.volley.toolbox. *-ne pas avertir com.facebook.infer. *

@ProHzen Cela a-t-il corrigé le plantage du soloader ?

Oui, je l'ai résolu.

il est toujours dans Fresco 2.0.0, :-( , veuillez suggérer une solution de contournement, je n'ai qu'un problème avec les périphériques Nexus

@ProHzen Bonjour, pouvez-vous m'envoyer votre liste de confusion? J'ai essayé comme vous l'avez fait, mais cela n'a pas fonctionné.
Info:
fresque:1.13.0
chemin de classe 'com.android.tools. build:grade :3.5.1'

Cette page vous a été utile?
0 / 5 - 0 notes

Questions connexes

eresid picture eresid  ·  4Commentaires

cococool picture cococool  ·  4Commentaires

bigfreeZhou picture bigfreeZhou  ·  4Commentaires

rhettor picture rhettor  ·  3Commentaires

hanhmh1203 picture hanhmh1203  ·  4Commentaires