Ich habe eine Android-Anwendung, die ich mit AOSP (Kitkat) als Android-System-Anwendung kompiliert und es lief gut. Meine Anwendung ist abhängig von nativem Code, der mit Android-NDK als 32-Bit-Bibliotheken kompiliert wurde. Ich kopiere native Bibliotheken in meinen Android-Anwendungen Ordner libs / armeabi und baue dann meine Android-Anwendung in AOSP (ich habe auch device.mk geändert, um meine libs in
Wenn ich meine Anwendung auf Android-L (64-Bit-Plattform) portiert habe, kann ich meine nativen Bibliotheken nicht von der Android-Anwendung laden und der Fehler ist wie -
java.lang.UnsatisfiedLinkError: dlopen failed: "libfoobar.so" is 32-bit instead of 64-bit
Ich verwende folgenden Java-Code, um native Bibliothek zu laden -
%Vor%Wenn ich meinen Code mit AOSP erstelle, ist ENABLE_ANDROID_INTEGRATION true
Interessanterweise, wenn ich ENABLE_ANDROID_INTEGRATION ausgeschaltet habe und meine Anwendung in Eclipse erstellte, außerhalb von AOSP als normale "herunterladbare" Anwendung, läuft meine Anwendung auf der 64-Bit Android-Plattform gut.
Was ich wissen möchte - wie kann ich meine Anwendung als native Android-Systemanwendung mit 32-Bit-Bibliotheken (das heißt AOSP-Build) für 64-Bit-Android-Plattform erstellen?
Was ich versucht habe - Ich habe LOCAL_32_BIT_ONLY = true -Flag in der Android.mk-Datei meiner Android-Anwendung verwendet, aber es scheint, dass es nicht nützlich ist. Vielleicht bin ich mir dieser Flagge nicht bewusst.
Da mir die Zeit davonläuft, habe ich es vorgezogen, diese Frage hier in der Gruppe anstatt in RnD zu posten. Wenn jemand mit diesem Problem konfrontiert wurde, dann bitte führen.
Grüße, Meraj
Der Grund, warum es bei der Installation als Drittanbieteranwendung funktioniert, ist, dass der Paketmanager bei der Installation die APK überprüft und prüft, ob sie native Bibliotheken verwendet. Wenn solche gefunden werden, speichert sie, welchen ABI sie verwendet haben installiert nur Bibliotheken für eine einzelne ABI, so dass die Information, welche Auswahl getroffen wurde, irgendwo gespeichert werden muss.)
Für eine Anwendung, die systemweit mit den Bibliotheken in / system / lib installiert ist, ist nicht klar, dass diese bestimmte Anwendung von einigen appspezifischen Bibliotheken in / system / lib abhängt (die in einer 64-Bit-Version nicht verfügbar sind / system / lib64), so dass der Paket- / Anwendungsmanager nicht wissen kann, dass diese bestimmte Anwendung eine bestimmte ABI benötigt und sie daher im 64-Bit-Modus ausführt.
Das Setzen von LOCAL_32_BIT_ONLY beeinflusst wahrscheinlich nur, ob es im 32-Bit-Modus kompiliert werden soll, nicht in welcher Weise es ausgeführt werden sollte.
Ein alter (und wahrscheinlich veralteter) Bericht bei Ссылка scheint darauf hinzuweisen, dass die nativen Bibliotheken für Apps in / system / lib / apkname gehen sollten, aber das scheint auf einem tatsächlichen Android 5.0-System nicht zu stimmen. Stattdessen scheinen sich die Bibliotheken in / system / app / Anwendungsname / lib / abiname zu befinden. Einige Anwendungen scheinen systemeigene Bibliotheken für mehrere Architekturen zu haben (zB "arm" und "arm64" als abiname ), während andere nur eine einzige Architektur haben (was den Prozess in diesem ABI erzwingen würde) Modus).
Ich denke also, Sie müssen den Mechanismus für die Installation Ihrer nativen Bibliotheken ändern (Sie haben gesagt, dass Sie device.mk manuell geändert haben) - ich bin nicht vertraut mit dem Erstellen eigener Apps als Teil eines AOSP-Builds, aber ich Ich würde empfehlen, die vorhandenen gebündelten Apps so zu betrachten, wie sie es tun. Dieses Commit hängt möglicherweise zusammen: Ссылка
Tags und Links 64bit android-ndk android-5.0-lollipop android-source