Wie kann man verschiedene Android-Architekturen ansprechen?

Ich verwende derzeit die OpenCV (OpenCV4Android) -Bibliothek, die das NDK nicht benutzt (es gibt keinen C- oder C ++ – Code). Allerdings gibt es .so Dateien für armeabi, armeabi-v7a, mips und x86. Wenn ich alle diese in das Projekt, die App-Größe ist 30mb, während, wenn ich nur 1, die App-Größe ist nur 9 MB. Wenn ich versuche, die App auf einem Gerät auszuführen, das nicht die Architektur dieses Gerätes hat, so ist die Datei enthalten, es stürzt ab, wohingegen es wenn es so ist.

Deshalb möchte ich mehrere APKs auf verschiedene Gerätearchitekturen verteilen, um die Dateigrößen zu reduzieren. Von dem, was ich gesehen habe, kann dies nur in der Application.mk-Datei gemacht werden, aber meine Bibliothek hat keine. Gibt es einen anderen Weg, um verschiedene Android-Architekturen zu erreichen?

  • Wie man actionbarsherlock menu item font Gesicht bei der Verwendung von benutzerdefinierten Thema für actionbar?
  • Verständnis von libgdx
  • Kann nicht die PreferenceFragment zu arbeiten (Kompilieren Fehler)
  • Skype startet Dialing und hängt nach 2 Sekunden - Android
  • Umgekehrte entgegengesetzte Farben
  • Facebook-Integration auf Android fbconnect defekten Link
  • Android NumberPicker wraps Werte, wenn die angezeigten Werte geändert werden
  • AlertDialog-Schaltflächen für eine Aktivität
  • 3 Solutions collect form web for “Wie kann man verschiedene Android-Architekturen ansprechen?”

    Ich verwende derzeit die OpenCV (OpenCV4Android) -Bibliothek, die das NDK nicht benutzt (es gibt keinen C- oder C ++ – Code). Allerdings gibt es .so Dateien für armeabi, armeabi-v7a, mips und x86.

    Als immibis es ausdrücke, wenn es so .so Dateien gibt, dann benutzt es das NDK.

    Wenn ich versuche, die App auf einem Gerät auszuführen, das nicht die Architektur dieses Gerätes hat, so ist die Datei enthalten, es stürzt ab, wohingegen es wenn es so ist.

    Das hängt vom Gerät ab. Viele x86-Geräte haben libhoudini , die ARM NDK-Binärdateien libhoudini können, wenn auch langsamer, als sie native x86-Binärdateien ausführen würden. Ähnlich kann ein armeabi-v7 Gerät armeabi NDK-Binärdateien armeabi , wenn auch vielleicht langsamer, besonders wenn die Gleitkomma-Verarbeitung verwendet wird.

    Deshalb möchte ich mehrere APKs auf verschiedene Gerätearchitekturen verteilen, um die Dateigrößen zu reduzieren. Von dem, was ich gesehen habe, kann dies nur in der Application.mk-Datei gemacht werden, aber meine Bibliothek hat keine.

    Die Datei Application.mk steuert nur, was kompiliert wird, nicht was verteilt wird.

    Gibt es einen anderen Weg, um verschiedene Android-Architekturen zu erreichen?

    Benutze Gradle für Android, vielleicht in Verbindung mit Android Studio und dem abi Split :

     android { ... splits { abi { enable true reset() include 'x86', 'armeabi-v7a', 'mips' universalApk true } } } 

    Der abi Verschluss im splits Verschluss:

    • Entscheidet sich für verschiedene APK-Dateien pro CPU-Architektur

    • Stellt eine Whitelist der Architekturen her, die Sie wollen

    • Fordert auch eine "universelle APK", die alle Architekturen enthält, für die Verwendung mit Vertriebskanälen, die keine separaten APKs durch Architektur unterstützen

    Das Ergebnis Ihres Builds sind separate APKs von CPU-Architektur, plus die universelle.

    Jeder Apk für die Anwendung sollte einen eindeutigen Versionscode haben, der von android:versionCode angegeben wird. Einige x86-Geräte können ARMv7-Binärdateien ausführen. Um einen Fall von ARMv7 zu vermeiden, der im x86-Gerät heruntergeladen / verwendet wird (und ähnliche Szenarien für andere Architekturen), sollten Sie die Versionscodes bestellen . Zum Beispiel, bestellen Sie die Version Codes, so dass die x86 APK hat einen höheren Versionscode als ARMv7. Mehr über die Versionierung auf diesem Link .

    Ein build.gradle Beispiel für die Erstellung von einzigartigen Version coded apks für jede Architektur Ihrer Wahl wird von ph0b bei github geteilt . Kopiere das gleiche unten.

     splits { abi { enable true reset() include 'x86', 'x86_64', 'armeabi-v7a', 'arm64-v8a' //select ABIs to build APKs for universalApk true //generate an additional APK that contains all the ABIs } } // map for the version code project.ext.versionCodes = ['armeabi': 1, 'armeabi-v7a': 2, 'arm64-v8a': 3, 'mips': 5, 'mips64': 6, 'x86': 8, 'x86_64': 9] android.applicationVariants.all { variant -> // assign different version code for each output variant.outputs.each { output -> output.versionCodeOverride = project.ext.versionCodes.get(output.abiFilter, 0) * 1000000 + android.defaultConfig.versionCode } } 

    Vorschlag: Android mehrere apk Unterstützung Dokumentation schlägt vor , nicht mehrere apks verwenden, wenn apk Größe ist weniger als 50 MB.

    Sie sollten in der Regel mehrere APKs verwenden, um verschiedene Gerätekonfigurationen nur zu unterstützen, wenn Ihr APK zu groß ist (größer als 50 MB) aufgrund der alternativen Ressourcen, die für unterschiedliche Gerätekonfigurationen benötigt werden. Mit einem einzigen APK, um verschiedene Konfigurationen zu unterstützen, ist immer die beste Praxis, denn es macht den Pfad für Anwendungs-Updates einfach und klar für Benutzer (und macht auch Ihr Leben einfacher durch die Vermeidung von Entwicklung und Veröffentlichung Komplexität).

    Ich empfehle nicht, dieses Muster zu verwenden, um deine Build-Nummer zu erstellen. ARCH – BUILD, denn wenn du eines Tages zu einer APK zurückkommst, musst du dein versionCode viel erhöhen. Stattdessen kannst du diesem Muster folgen: BUILD – ARCH

     android.defaultConfig.versionCode * 100 + project.ext.versionCodes.get(output.getFilter(com.android.build.OutputFile.ABI), 0) 

    Beispiel für Build 74 die Build-Nummer wird sein: 7402 – armeabi-v7a 7408 – x86

    Das Android ist ein Google Android Fan-Website, Alles ├╝ber Android Phones, Android Wear, Android Dev und Android Spiele Apps und so weiter.