Ich habe eine JNI-Bibliothek, die auf den meisten Android-Geräten gut läuft - ARMv5, ARMv7 und x86.
Ich benutze NEON-Anweisungen auf ARMv7, aber anstatt den Code mit bedingter / duplizierter Quelle zu überfluten, möchte ich einen Nicht-NEON-ARMv7 in Java beim Laden der Bibliothek entdecken und stattdessen die v5-Bibliothek laden: langsame CPU ist langsam.
Ich habe einen Beitrag gefunden, der darauf hinweist, dass ich nach der "Neon" -Funktion in / proc / cpuinfo suche, also analysiere ich das und lade in der Regel loththing.so oder libthing-v5.so, wenn das Gerät behauptet, ein ARMv7 ohne NEON. Dies funktioniert gut auf ARM.
Leider emuliert x86 nicht nur ein ARM / proc / cpuinfo (!), wenn es entscheidet, dass es NEON nicht versteht, dann gräbt es auch libthing-v5.so aus dem armeabiv7a-Verzeichnis aus und verwendet es, weil es nicht existiert 't eins im x86 Verzeichnis.
Meine aktuelle Problemumgehung besteht darin, die x86-Bibliothek sowohl in lything.so als auch in libthing-v5.so zu kopieren. Wenn also x86 vorgibt, ein NEON-freier ARMv7-Chip zu sein, wird es sowieso die x86-Bibliothek bekommen.
>Abgesehen davon, dass ich eine kleine eigene eigenständige Architektur-Erkennungsbibliothek auf Basis von Yeppp oder Androids eigenen CPU-Funktionen aufbaut, gibt es eine Möglichkeit, die echte lokale Architektur von Java zu bestimmen?
@ ph0b: Hiermit wird der Ausgang des Razr i angezeigt, der zeigt, dass der Emulator entschieden hat, dass die Anwendung als 'ABI2 58' installiert wurde und dass er / proc / cpuinfo vortäuschen muss.
Da beide shared libraries sowohl in x86 als auch in den Armeabi * -Verzeichnissen verfügbar sind, verstehe ich nicht, warum sich das Gerät als ARM entschieden hat. Ich könnte meinen Kontakt bei Intel dazu fragen.
%Vor%Ich bezweifle, dass das x86 ein ARM / proc / cpuinfo! emuliert?
Wie auch immer, um die lokale Architektur von Java zu erkennen, können Sie sich auf Build.CPU_ABI und Build.CPU_ABI2 verlassen: Ссылка und dann mit der Analyse von / proc / cpuinfo fortfahren, um nach neon zu suchen, wenn CPU_ABI und CPU_ABI2 arm * / armeabi-v7a
Sie können sich nicht auf proc / cpuinfo, getProperty ("os.arch") oder Build.CPU_ABI (2) verlassen. Sie sind alle falsch, wenn die Emulation aktiv ist. Die Art, wie ich die Erkennung mache, analysiere ich die / proc / cpuinfo Suche nach einem Wort "Platzhalter". Es ist in "Hardware:" Zeile. Normalerweise gibt es einen echten Firmennamen wie "Samsung" für Samsung Galaxy, aber im Falle der ARM-Emulation auf x86 sehe ich, dass es nur einen "Platzhalter" in der Hardwarezeile in / proc / cpuinfo gibt. Ich habe es nicht an vielen Gerätemodellen getestet, kann also nicht sagen, wie zuverlässig das ist.
Sie können auch den im ELF-Dateiheader definierten e_machine -Wert abrufen, z. B. die Datei libc.so , um festzustellen, welche Architektur angegeben wurde.
Codeausschnitt:
%Vor% Wenn Build.CPU_ABI anzeigt, dass Sie auf ARM laufen, aber mit dem x86 em in Konflikt geraten, emuliert es!
So schrecklich das klingt, wenn Sie eine andere Liste von nativen Bibliotheken für ARM und x86 haben, dann werden Geräte wie das Programm automatisch dazu übergehen, die Anwendung unter dem ARM-Emulator auszuführen.
Tags und Links x86 android-ndk arm