0 votes

whiteSkar avatar

dlopen failed : bibliothèque "/system/lib/libhoudini.so" non trouvée

Demandé el 22 de Décembre, 2014
Quand la question a-t-elle été
8169 affichage
Nombre de visites la question a
1 Réponses
Nombre de réponses aux questions
Résolu
Situation réelle de la question

Mon jeu Android est construit avec cocos2dx 3.0, et il fonctionne bien sur mon Nexus 5. Cependant, mes amis qui ont un Galaxy S4 disent que le jeu se plante à l'ouverture.

Modifier : testé avec plus d'appareils. Fonctionne sur Nexus 5 Lollipop et Nexus 7 Lollipop. Ne fonctionne pas sur Galaxy S4 KitKat, Galaxy Note 3 KitKat et Nexus 5 KitKat. Il semble que cela fonctionne sur l'API 21 mais pas sur la 19. Cependant, j'ai réglé les deux minSDKversion et la version cible à 19 qui est KitKat)

J'ai donc téléchargé l'émulateur Genymotion pour simuler sur le Galaxy S4 puisque l'émulateur Android SDK ne semblait pas avoir le Galaxy S4 dans la liste. Puis j'ai découvert que Genymotion ne fonctionne pas avec les APKs construits pour ARM. Par conséquent, j'ai ajouté la ligne APP_ABI := armeabi armeabi-v7a x86 en application.mk pour que l'APK supporte les trois architectures.

Aussi, j'ai modifié le code de cocos2dx pour traiter Genymotion comme émulateur.

if (product != null) {
    isEmulator = product.equals("sdk") || product.contains("_sdk") || product.contains("sdk_") || product.contains("vbox");
} // vbox part is the added part

Maintenant, lorsque j'installe et exécute l'APK sur l'émulateur S4, il se bloque avec l'erreur disant

12-22 22:22:34.502: D/Cocos2dxActivity(1280): model=Samsung Galaxy S4 - 4.4.4 - API 19 - 1080x1920
12-22 22:22:34.506: D/Cocos2dxActivity(1280): product=vbox86p
12-22 22:22:34.506: D/Cocos2dxActivity(1280): isEmulator=true
12-22 22:22:34.510: D/dalvikvm(1280): Trying to load lib /data/app-lib/com.DoomChitGames.LittleSnake-2/libcocos2dcpp.so 0xa508c970
12-22 22:22:34.514: E/dalvikvm(1280): dlopen("/data/app-lib/com.DoomChitGames.LittleSnake-2/libcocos2dcpp.so") failed: dlopen failed: library "/system/lib/libhoudini.so" not found
12-22 22:22:34.514: D/AndroidRuntime(1280): Shutting down VM
12-22 22:22:34.514: W/dalvikvm(1280): threadid=1: thread exiting with uncaught exception (group=0xa4d00b20)
12-22 22:22:34.514: E/AndroidRuntime(1280): FATAL EXCEPTION: main
12-22 22:22:34.514: E/AndroidRuntime(1280): Process: com.DoomChitGames.LittleSnake, PID: 1280
12-22 22:22:34.514: E/AndroidRuntime(1280): java.lang.UnsatisfiedLinkError: dlopen failed: library "/system/lib/libhoudini.so" not found
12-22 22:22:34.514: E/AndroidRuntime(1280):     at java.lang.Runtime.loadLibrary(Runtime.java:364)
12-22 22:22:34.514: E/AndroidRuntime(1280):     at java.lang.System.loadLibrary(System.java:526)
12-22 22:22:34.514: E/AndroidRuntime(1280):     at org.cocos2dx.lib.Cocos2dxHelper.init(Cocos2dxHelper.java:94)
12-22 22:22:34.514: E/AndroidRuntime(1280):     at org.cocos2dx.lib.Cocos2dxActivity.onCreate(Cocos2dxActivity.java:84)
12-22 22:22:34.514: E/AndroidRuntime(1280):     at android.app.Activity.performCreate(Activity.java:5231)
12-22 22:22:34.514: E/AndroidRuntime(1280):     at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1087)
12-22 22:22:34.514: E/AndroidRuntime(1280):     at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2148)
12-22 22:22:34.514: E/AndroidRuntime(1280):     at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2233)
12-22 22:22:34.514: E/AndroidRuntime(1280):     at android.app.ActivityThread.access$800(ActivityThread.java:135)
12-22 22:22:34.514: E/AndroidRuntime(1280):     at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1196)
12-22 22:22:34.514: E/AndroidRuntime(1280):     at android.os.Handler.dispatchMessage(Handler.java:102)
12-22 22:22:34.514: E/AndroidRuntime(1280):     at android.os.Looper.loop(Looper.java:136)
12-22 22:22:34.514: E/AndroidRuntime(1280):     at android.app.ActivityThread.main(ActivityThread.java:5001)
12-22 22:22:34.514: E/AndroidRuntime(1280):     at java.lang.reflect.Method.invokeNative(Native Method)
12-22 22:22:34.514: E/AndroidRuntime(1280):     at java.lang.reflect.Method.invoke(Method.java:515)
12-22 22:22:34.514: E/AndroidRuntime(1280):     at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:785)
12-22 22:22:34.514: E/AndroidRuntime(1280):     at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:601)
12-22 22:22:34.514: E/AndroidRuntime(1280):     at dalvik.system.NativeStart.main(Native Method)
12-22 22:22:38.490: I/Process(1280): Sending signal. PID: 1280 SIG: 9

Quelqu'un sait-il quel est le problème ?

Demandé el 22 de Décembre, 2014 par whiteSkar

Réponse

Trop de publicités?

2voto

PsychoBoyJack avatar
PsychoBoyJack Points 36

Houdini est une bibliothèque fournie par Intel pour convertir les intrinsèques ARM NEON en instructions SSE correspondantes au moment de l'exécution. Il semble que cocos (ou votre jeu) utilise toujours NEON même si vous compilez maintenant pour x86.

Cela peut être aussi simple que de faire une reconstruction complète pour s'assurer que tous les fichiers objets sont recompilés en respectant votre modification de l'ABI :

ndk-build -B <your_normal_parameters>

Assurez-vous également que tous les autres fichiers Application.mk sont mis à jour avec les nouveaux ABIs.

Si cette solution rapide ne fonctionne pas, j'essaierais de créer un émulateur x86 normal en utilisant le SDK Android et HAXM . Si vous rencontrez toujours des problèmes, il se peut que votre problème soit un peu plus difficile à diagnostiquer compte tenu des informations que vous avez fournies.

Cependant, je pense que vous vous donnez plus de travail que nécessaire.

Demandez à vos amis ayant un S4 d'activer " Rapports de bogues sur le menu d'alimentation "sous Paramètres / Système / Options du développeur. Demandez-leur d'exécuter votre application, et après qu'elle se soit plantée, demandez-leur de maintenir le bouton d'alimentation enfoncé et de sélectionner "Rapport de bug". Une fois l'application terminée, il peut vous l'envoyer par e-mail et vous aurez la pile complète et de nombreuses autres informations qui vous aideront à déterminer le problème réel sur son S4.

Une autre option consiste à étendre l'application dans votre application, et définissez une classe Gestionnaire d'exception non attrapée . Lorsque votre application se bloque à cause d'une exception non attrapée, vous pouvez alors faire quelque chose avec l'exception - enregistrer la pile dans un fichier texte sur la carte SD, l'envoyer par e-mail, etc. Mais si le crash se produit dans du code natif, vous n'obtiendrez peut-être pas beaucoup d'informations utiles à partir de l'exception.

HTH.

Répondu el 23 de Décembre, 2014 par PsychoBoyJack (36 Points )

Questions en vedette

Top Tags

Dans notre réseau

androidalle.com

AndroidAlle est une communauté de androiders où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

Yandex
X