2012-04-07 2 views
2

Hier ist die Situation: Ich habe eine native Bibliothek für die erneute Verteilung in anderen Anwendungen erstellt. Da wir ARMv7 NEON verwenden, liefern wir zwei Versionen der Bibliothek: Eine für die meisten Geräte und eine "Fallback" -beschränkte Version für ARMv5/ARMv6. So weit, so gut und das hat gut funktioniert.Android 4.0 entpackt das falsche EABI für die enthaltene Bibliothek

Aus irgendeinem Grund nimmt eine neu erstellte App, die auf einem Nexus S mit Android 4.0.3 läuft, die falsche (armeabi statt arméabi-v7a) Version der Bibliothek auf.

Wenn wir uns in das Dateisystem des Geräts vertiefen, finden wir, dass /data/app/my_app.apk die korrekten Versionen der Bibliothek enthält. Wenn Android jedoch nach/data/data/my_app extrahiert wird, finden wir, dass /data/data/my_app/lib/my_lib.so die armeabi-Version ist. Aber seltsamerweise ist /data/data/my_other_app/lib/my_lib.so die korrekte armea-v7a-Version. Die Fragen lauten also: 1) WTF ?? 2) Wie entscheidet Android, welches eabi aus der APK extrahiert werden soll?

+0

Ich möchte auch, dass my_app.apk erwähnen läuft sehr gut auf einem Android 2.2.1 Telefon. Das führt uns zurück zu Frage Nr. 1. – tomwhipple

Antwort

2
+0

Dies scheint zu entsprechen, was passiert, aber die Frage bleibt: Warum tritt das Problem in einer App und nicht die andere, wenn beide die gleiche gebündelte Bibliothek verwenden? – tomwhipple

+0

Im ersten Link wird darüber gesprochen, welche Bibliothek auf Armea-v7a entpackt wird, hängt von der Reihenfolge der SO-Dateien im APK-Archiv ab. Vielleicht passiert das gerade. –

+0

Das macht Sinn, aber scheint seltsam, dass die Reihenfolge in jedem Projekt konsistent (und durchweg unterschiedlich) ist ... Ich habe mehrere Versionen der funktionierenden App ohne Probleme erstellt. ABER, scheint eine getrennte Fähigkeitsbibliothek zu arbeiten, also werde ich es nicht viel weiter verfolgen. Danke für die Links !! – tomwhipple

Verwandte Themen