Verständnis der Android-CPU-Architektur (ABI): Warum arm64-v8a, armeabi-v7a und x86 wichtig sind

Wenn Sie schon einmal eine Reihe geteilter APK-Dateien zusammengeführt haben und zusehen mussten, wie Ihr Telefon die Meldung „App nicht installiert“ zurückgab oder schlimmer noch, die Installation einwandfrei funktionierte und in dem Moment abstürzte, in dem Sie auf das Symbol tippten, besteht eine gute Chance, dass das eigentliche Problem nichts mit einem beschädigten Download zu tun hatte. Es ging mit ziemlicher Sicherheit um die Architektur: eine Diskrepanz zwischen der CPU, auf der Ihr Telefon läuft, und der CPU, für die der native Code der App kompiliert wurde. Die meisten Android-Benutzer müssen nie darüber nachdenken, bis es stillschweigend etwas kaputt macht und es dann schnell relevant wird. Hier erfahren Sie, was CPU-Architektur für ein APK bedeutet, warum eine einzelne App im Play Store heimlich in mehreren unterschiedlichen Builds ausgeliefert wird und wie Sie die Kompatibilität überprüfen können, bevor Sie etwas installieren.

Was ein ABI ist

ABI steht für Application Binary Interface. In der Praxis handelt es sich um den Befehlssatz, den ein Chip versteht – das rohe Maschinencodeformat, das ein Prozessor direkt ausführen kann. Der größte Teil einer Android-App, die in Java oder Kotlin geschriebenen Teile, wird in Bytecode kompiliert, der in der Android Runtime (ART) ausgeführt wird, und ART ist es egal, auf welchem ​​Chip sie sich gerade befindet. Diese Ebene ist vom Design her architekturunabhängig, was ein wesentlicher Grund dafür ist, dass Android-Apps im Allgemeinen auf einer so breiten Palette von Hardware „einfach funktionieren“.

Nativer Code ist eine andere Geschichte. Viele Apps, insbesondere Spiele, Kamera-Apps, Tools für maschinelles Lernen und alles, was eine umfangreiche Audio- oder Videoverarbeitung erfordert, liefern über das Android NDK native Bibliotheken, die in C oder C++ geschrieben sind. Diese Bibliotheken werden vorab in Maschinencode für einen bestimmten Befehlssatz kompiliert, und ein Chip, der für einen Befehlssatz gebaut wurde, kann im Allgemeinen keinen Maschinencode ausführen, der für einen anderen Befehlssatz geschrieben wurde. Aus diesem Grund gibt es ABIs als etwas, das es wert ist, verstanden zu werden: Sobald eine App auch nur eine native .so-Bibliothek enthält, wird ihre Kompatibilität an die Architekturen gebunden, für die die Bibliothek erstellt wurde.

Die Architekturen, denen Sie begegnen werden

Früher gab es in diesem Bereich mehr Vielfalt (erinnern Sie sich an einfaches armeabi oder MIPS?), aber bis 2026 ist das Feld auf vier wissenswerte ABIs eingegrenzt:

Wenn Sie ein Telefon besitzen, das Sie in den letzten fünf oder sechs Jahren gekauft haben, handelt es sich mit ziemlicher Sicherheit um arm64-v8a. Die Ausnahmen, an die man sich erinnern sollte, sind Emulatoren und Chromebooks, die häufig stattdessen auf x86_64 laufen, da dies der zugrunde liegenden Laptop- oder Desktop-CPU entspricht.

Warum Apps überhaupt die Mühe machen, mehrere Builds zu versenden

Eine offensichtliche Frage ist, warum Entwickler nicht einfach die nativen Bibliotheken jeder Architektur in ein einziges APK packen und damit fertig sind. Einige Apps tun genau das und man spricht von einer universellen oder „fetten“ APK. Der Nachteil ist die Größe. Ein Spiel mit nativen Bibliotheken für arm64-v8a, armeabi-v7a, x86 und x86_64, die alle gebündelt sind, kann die Größe leicht verdoppeln oder verdreifachen, verglichen mit einem Build, der nur die eine Architektur enthält, die Ihr Gerät benötigt. Wenn Sie das mit Millionen von Installationen multiplizieren, sehen Sie eine wirklich erhebliche Menge an verschwendeter Bandbreite und Speicherplatz für Code, der niemals auf diesem Gerät ausgeführt werden kann.

Um diese Verschwendung zu vermeiden, teilen Google Play und das Android App Bundle-Format eine App in ein kleines Basis-APK und eine Reihe von Konfigurations-APKs auf, von denen eines der Architektur gewidmet ist. Wenn Ihr Telefon die App anfordert, stellt der Play Store die Basis-APK zusammen mit nur der Architekturaufteilung bereit, die zu Ihrem Chip passt, zusammen mit passenden Bildschirmdichte- und Sprachaufteilungen. Am Ende erhalten Sie eine Installation, die sich wie eine einzelne App verhält, aber hinter den Kulissen aus mehreren speziell entwickelten Teilen zusammengesetzt ist.

Wie Split-APKs und App-Bundles dies nutzen

Wenn Sie jemals ein .apks- oder .xapk-Paket geöffnet haben und Dateinamen wie split_config.arm64_v8a.apk, split_config.armeabi_v7a.apk, split_config.xxhdpi.apk und split_config.en.apk neben einem base.apk bemerkt haben, dann ist das genau dieses System in Aktion, nur als Dateisatz exportiert, anstatt stillschweigend vom Play Store bereitgestellt zu werden. Dichte- und Sprachaufteilungen können normalerweise problemlos wahllos installiert werden, da ein Telefon Ressourcen, die es nicht benötigt, einfach ignoriert. Die Architekturaufteilung ist anders: Installieren Sie die falsche oder scheitern Sie daran, die passende zu installieren, und Sie werden in echte Schwierigkeiten geraten.

Wenn Sie einen Konverter verwenden, um ein geteiltes Paket wieder in ein einziges installierbares APK zusammenzuführen, muss der Zusammenführungsprozess auswählen, welche Architektur-Splits eingefügt werden sollen. Ein guter Konverter behält jede Architektur-Splittung bei, die wirklich nützlich ist, oder lässt Sie wählen, anstatt stillschweigend nur eine zu behalten und zu hoffen, dass sie zu Ihrem Gerät passt.

Was passiert, wenn die Architektur nicht passt?

Es gibt zwei unterschiedliche Fehlermodi, die man kennen sollte, da sie für einen normalen Benutzer anders aussehen und sich anders anfühlen.

Das erste ist ein völliger Installationsfehler. Wenn eine App fast ausschließlich auf nativem Code ohne sinnvollen Fallback basiert, lehnt der Paketmanager von Android die Installation überhaupt ab und zeigt normalerweise einen Fehler wie INSTALL_FAILED_NO_MATCHING_ABIS an. Sie werden die App nie öffnen können; Der Installateur hält Sie an der Tür an.

Das zweite, frustrierendere Ergebnis ist ein stiller Teilerfolg. Wenn eine App über einen Java- oder Kotlin-Einstiegspunkt verfügt, der selbstständig geladen werden kann, dann aber versucht, eine native Bibliothek aufzurufen, die für Ihre Architektur einfach nicht vorhanden ist, wird die Installation normal abgeschlossen. Alles sieht gut aus, bis Sie auf das Symbol tippen. Dann stürzt die App fast sofort ab, oft mit einem UnsatisfiedLinkError, der in den Protokollen vergraben ist. Dies ist die klassische Geschichte „Ich habe es konvertiert, es wurde installiert und dann wird es sofort geschlossen“, und es handelt sich fast immer eher um ein Architekturproblem als um eine beschädigte Datei.

So überprüfen Sie die Architektur Ihres eigenen Telefons

Für die überwiegende Mehrheit der Menschen ist das einfach: Wenn Ihr Telefon aus dem Jahr 2019 oder später ist, nehmen Sie arm64-v8a an und machen Sie weiter. Wenn Sie sicher sein möchten oder es sich um ein älteres oder ungewöhnliches Gerät handelt, gibt es einige praktische Möglichkeiten:

• Suchen Sie nach dem genauen Chipsatzmodell Ihres Telefons (sichtbar auf der Verpackung, im Handbuch oder auf einer Website wie GSMArena) und prüfen Sie, ob es sich bei dem Chipsatz um einen 32-Bit- oder einen 64-Bit-ARM-Chipsatz handelt.
• Installieren Sie eine einfache Systeminformations-App, die die CPU-Architektur direkt meldet. Für diesen Zweck gibt es mehrere kostenlose Apps.
• Überprüfen Sie, ob das Telefon mit Android 9 oder höher als Originalversion des Betriebssystems ausgeliefert wurde. Aufgrund der 64-Bit-Anforderungen von Google aus dieser Zeit ist arm64-v8a im Wesentlichen für alles garantiert, was qualifiziert ist.

So überprüfen Sie, welche Architekturen ein APK unterstützt

Bevor Sie eine Datei von außerhalb des Play Stores installieren, lohnt es sich, den Inhalt zu überprüfen, anstatt zu raten. Die nativen Bibliotheken eines APK befinden sich in Ordnern, die nach ihrer Architektur im lib/-Verzeichnis benannt sind, z. B. lib/arm64-v8a/ oder lib/armeabi-v7a/. Jedes Tool, das die interne Struktur einer APK untersuchen kann, kann Ihnen genau sagen, welche dieser Ordner vorhanden sind, und somit genau sagen, auf welchen Geräten die Datei ausgeführt wird.

Universal-APK vs. Single-ABI-APK: Welches sollten Sie verwenden?

Häufige Fehler, die Menschen mit geteilten Paketen machen

• Vorausgesetzt, jede Aufteilung ist optional. Dichte- und Sprachaufteilungen sind normalerweise vorhanden, die Architekturaufteilung jedoch nicht. Überspringen Sie es niemals während einer Zusammenführung.
• Erfassen nur einer Architektur, die von einer Spiegel-Site getrennt wurde. Wenn ein Drittanbieter-Download beispielsweise nur das armeabi-v7a-Slice anbietet, schlägt er möglicherweise einfach auf einem Gerät fehl, das stattdessen arm64-v8a benötigt, obwohl die App selbst legitim ist.
• Vergessen Sie, dass Tablets und Chromebooks nicht immer ARM sind. Viele Chromebooks mit Android-Apps und einige ältere Tablets sind x86 oder x86_64 statt ARM.
• Testen einer reinen ARM-APK in einem x86-Emulator. Einige ältere Emulator-Builds laufen auf x86, und ein APK, das nur native ARM-Bibliotheken liefert, wird darin einfach nicht gestartet, unabhängig davon, wie das APK verpackt wurde.
• Verwechslung von „universal“ mit „Einzel-ABI“. Ein universelles APK ist absichtlich größer, weil es alles enthält; Ein Single-ABI-APK ist klein und absichtlich auf eine Chipfamilie beschränkt.

Häufig gestellte Fragen (FAQ)

Sie müssen sich nichts davon merken. Die Kurzfassung: Moderne Telefone sind fast immer arm64-v8a, Apps werden nach Architektur aufgeteilt, um Platz zu sparen, und wenn sich etwas nicht installieren lässt oder direkt nach dem Öffnen abstürzt, ist eine Nichtübereinstimmung der Architektur eines der ersten Dinge, die man ausschließen sollte, bevor man davon ausgeht, dass die Datei selbst beschädigt ist.