wie verwenden von 32-bit native-Bibliotheken auf 64-bit-Android-L-Plattform

Ich habe ein Android-Anwendung, die ich zusammengestellt mit AOSP(Kitkat) android-system Anwendung und es lief gut. Meine Anwendung ist abhängig von native code kompiliert mit Android-NDK als 32-bit-Bibliotheken. Ich bin kopieren nativen Bibliotheken in meinem android-Anwendungen libs/armeabi Ordner und dann mit dem Aufbau meiner android-App im AOSP(habe ich auch geändert Gerät.mk kopieren meine libs in die /system/lib Ordner). Alles funktioniert auf Android Kitkat.

Als ich portiert meine Anwendung auf Android-L(64-bit-Plattform), dann bin ich nicht in der Lage zu laden meine native Bibliotheken von Android-Anwendung und Fehler wie -

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

Ich bin mit dem folgenden java-code zum laden der native-Bibliothek-

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

Wenn ich Baue meinen code mit AOSP dann ENABLE_ANDROID_INTEGRATION ist wahr

Interessanter, wenn ich ausgeschaltet ENABLE_ANDROID_INTEGRATION und bauen meine Anwendung in Eclipse, die außerhalb AOSP als normaler "herunterladbare" Anwendung dann meine Anwendung läuft problemlos auf 64-bit-Android-Plattform.

Was ich wissen möchte - wie kann ich meine Anwendung als native android-system-Anwendung mit 32-bit-Bibliotheken(also AOSP build) für 64-bit-Android-Plattform?

Was ich versucht habe - ich habe LOCAL_32_BIT_ONLY = true Flagge in meinem android Anwendung, Android.mk-Datei, aber es scheint nicht sinnvoll. Kann sein ich bin nicht voll und ganz bewusst, dieses flag verwenden.

So, ich bin running out of time so zog ich Stelle diese Frage hier in der Gruppe anstelle von RnD. Wenn jemand angesichts dieses Problems dann bitte guide.

Grüße,
Meraj

InformationsquelleAutor Meraj Ahmad | 2014-12-30
  1. 8

    Der Grund, warum es funktioniert, wenn installiert als eine Drittanbieter-Anwendung, ist, dass bei der installation der Paket-manager durchsucht die APK und prüft, ob es verwendet native Bibliotheken, und wenn solche gefunden werden, speichert es das ABI, die Sie verwendet (da es nur installiert die Bibliotheken, die für eine einzelne ABI, also die Informationen darüber, welche Wahl getroffen wurde, muss irgendwo gespeichert werden).

    Für eine Anwendung, die installiert ist systemweit mit den Bibliotheken in /system/lib, es ist nicht klar, dass diese bestimmte Anwendung hängt davon ab, einige app-spezifische libs in /system/lib (die nicht in einer 64 bit-version in der /system/lib64), so dass das Paket/Programm-manager können nicht wissen, dass diese Besondere app erfordert eine spezifische ABI und so läuft es im 64 bit-Modus.

    Einstellung LOCAL_32_BIT_ONLY wohl nur beeinflusst, ob Sie kompiliert werden soll in 32-bit-Modus, nicht in der Art, wie es ausgeführt werden soll.

    Einem alten (und vermutlich veralteten) Bericht an http://www.slideshare.net/hidenorly/investigation-result-on-64-bit-support-in-aosp scheint zu besagen, dass die nativen Bibliotheken für die apps in /system/lib/apkname, aber dies scheint nicht wahr zu sein, auf eine aktuelle Android 5.0-system. Stattdessen werden die libs scheinen sich in /system/app/appname/lib/abiname. Einige apps scheinen nativen libs für mehrere Architekturen (z.B. sowohl "arm" und "arm64" als abiname), während andere nur eine einzige Architektur (die Kraft, die den Prozess gestartet werden, dass der ABI-Modus).

    So, ich glaube, Sie brauchen, zu ändern, den Mechanismus für die Vorgehensweise bei der Installation Ihrer nativen Bibliotheken (Sie sagte, Sie manuell geänderte Gerät.mk) - ich bin nicht vertraut mit, wie das erstellen eigener apps, die als Teil einer AOSP-build, aber ich würde empfehlen, versuchen, Blick auf die bestehenden gebündelten Anwendungen, wie Sie es tun, diese Begehen kann bezogen werden: https://android.googlesource.com/platform/packages/apps/Terminal/+/1a161f75%5E%21/

    • Vielen Dank für diese Informationen. Es hat mir geholfen, eine Menge, die Bewegung in die richtige Richtung.
    • Hallo @MerajAhmad, ich stehe vor ähnlichen problem, können Sie beschreiben, wie Sie das gemacht haben? Danke
    InformationsquelleAutor mstorsjo
  2. 4

    Ich habe das gleiche problem und fand die Antwort hier und hier
    Löschen Sie alle 64-bit-Bibliotheken und Links nur 32-bit-libs:
    In Android.mk: 

    APP_API := armeabi armeabi-v7a x86 mips

    In bauen.gradle(Module:app):

    ndk {
    moduleName "<module_name>"
    abiFilters "armeabi", "armeabi-v7a", "x86", "mips"
}
    • in der Tat nur das abiFilters "armeabi", "armeabi-v7a", "x86", "mips" Teil, zusammen mit android.useDeprecatedNdk=true innerhalb von gradle.Eigenschaften genug zu sein scheint.
    • das ist wahr, aber jetzt google play-Konsole wird einen Fehler auslösen, wenn Sie nicht verwendet 64-bit-libs in Ihre app, wenn Sie gehen, um roll-out Ihre Anwendung
    InformationsquelleAutor Dmitry Velychko
  3. 0

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

    Versuchen, diese in Ihrem Android.mk
    LOCAL_MULTILIB := 32

    InformationsquelleAutor AudiO
Schreibe einen Kommentar