web-dev-qa-db-fra.com

comment utiliser les bibliothèques natives 32 bits sur la plate-forme Android-L 64 bits

J'ai une application Android que j'ai compilée avec AOSP (KitKat) comme application système Android et tout fonctionnait bien. Mon application dépend du code natif compilé avec Android-NDK sous forme de bibliothèques 32 bits. Je copie des bibliothèques natives dans mes applications Android libs/armeabi dossier, puis je construis mon application Android sous AOSP (j'ai également modifié device.mk pour copier mes bibliothèques dans/system/lib dossier). Tout fonctionne correctement sur Android KitKat.

Lorsque j'ai porté mon application sur Android-L (plate-forme 64 bits), je ne suis pas en mesure de charger mes bibliothèques natives à partir d'une application Android et l'erreur est semblable à -

Java.lang.UnsatisfiedLinkError: dlopen failed: "libfoobar.so" is 32-bit instead of 64-bit

J'utilise le code Java suivant pour charger la bibliothèque native-

        if ( ENABLE_Android_INTEGRATION )
        {
            System.load("/system/lib/libfoobar.so");
        }
        else
        {
            System.loadLibrary("foobar");
        }

Quand je construis mon code avec AOSP, alors ENABLE_Android_INTEGRATION est vrai

Plus intéressant encore, lorsque j'ai désactivé ENABLE_Android_INTEGRATION et que j'ai construit mon application dans Eclipse, en dehors de AOSP en tant qu'application "téléchargeable" normale, mon application s'exécute correctement sur la plate-forme Android 64 bits.

Ce que je veux savoir - comment puis-je créer mon application en tant qu'application système Android native avec des bibliothèques 32 bits (c'est-à-dire une version AOSP) pour une plateforme Android 64 bits?

Ce que j'ai essayé - J'ai utilisé LOCAL_32_BIT_ONLY = true flag dans le fichier Android.mk de mon application Android, mais il semble que ce ne soit pas utile. Peut-être que je ne suis pas tout à fait au courant de l'utilisation de ce drapeau.

Comme je manque de temps, j’ai préféré poster cette question ici en groupe au lieu de RnD. Si quelqu'un fait face à ce problème, alors s'il vous plaît guider.

Cordialement, Meraj

9
Meraj Ahmad

La raison pour laquelle cela fonctionne lorsqu’il est installé en tant qu’application tierce, c’est que lors de l’installation, le gestionnaire de paquets analyse l’APK et vérifie s’il utilise des bibliothèques natives et, le cas échéant, stocke l’ABI qu’il a utilisée (puisqu’il installe uniquement des bibliothèques. pour un seul ABI, les informations sur le choix qui a été fait doivent donc être stockées quelque part).

Pour une application installée à l’échelle du système avec les bibliothèques de/system/lib, il n’est pas clair que cette application particulière dépend de bibliothèques spécifiques à une application de/system/lib (qui ne sont pas disponibles dans une version 64 bits de/system/lib64), de sorte que le gestionnaire de packages/applications ne peut pas savoir que cette application particulière nécessite une ABI spécifique et l'exécute donc en mode 64 bits.

La définition de LOCAL_32_BIT_ONLY n'affecte probablement que si elle doit être compilée en mode 32 bits, et non de quelle manière elle doit être exécutée.

Un ancien rapport (probablement obsolète) sur http://www.slideshare.net/hidenorly/investigation-result-on-64-bit-support-in-aosp semble suggérer que les bibliothèques natives pour applications devraient allez dans/system/lib/apkname, mais cela ne semble pas être vrai sur un système Android 5.0 réel. Au lieu de cela, les bibliothèques semblent se trouver dans/system/app/appname/lib/abiname. Certaines applications semblent avoir des bibliothèques natives pour plusieurs architectures (par exemple, "arm" et "arm64" en tant que abiname), tandis que d'autres ne possèdent qu'une seule architecture (ce qui obligerait le processus à démarrer en mode ABI).

Je pense donc que vous devez modifier le mécanisme d’installation de vos bibliothèques natives (vous avez dit que vous avez modifié manuellement device.mk). Je ne connais pas bien la façon de créer ses propres applications dans le cadre d’une version AOSP, mais je vous le recommande. en essayant de regarder les applications groupées existantes et comment ils le font, cette validation peut être liée: https://Android.googlesource.com/platform/packages/apps/Terminal/+/1a161f75%5E%21/

8
mstorsjo

J'ai le même problème et j'ai trouvé la réponse ici et ici Supprimez toutes les bibliothèques 64 bits et ne conserve que les bibliothèques 32 bits:

APP_API := armeabi armeabi-v7a x86 mips

Dans build.gradle (module: app):

ndk {
    moduleName "<module_name>"
    abiFilters "armeabi", "armeabi-v7a", "x86", "mips"
}
4
Dmitry Velychko

https://source.Android.com/source/64-bit-builds.html

Essayez ceci dans votre Android.mk LOCAL_MULTILIB: = 32

0
AudiO