Unterstützung für mehrere APKs

Wenn Sie Ihre App bei Google Play veröffentlichen, sollten Sie ein Android App Bundle erstellen und hochladen. In diesem Fall generiert Google Play automatisch optimierte APKs für die Gerätekonfiguration jedes Nutzers und stellt sie bereit, sodass nur der Code und die Ressourcen heruntergeladen werden, die zum Ausführen deiner App erforderlich sind. Die Veröffentlichung mehrerer APKs ist nützlich, wenn du nicht bei Google Play veröffentlichst, aber jedes APK selbst erstellen, signieren und verwalten musst.

Die Unterstützung mehrerer APKs ist eine Funktion bei Google Play, mit der Sie verschiedene APKs für Ihre App veröffentlichen können, die jeweils auf unterschiedliche Gerätekonfigurationen ausgerichtet sind. Jedes APK ist eine vollständige und unabhängige Version Ihrer App. Sie haben jedoch denselben App-Eintrag bei Google Play, müssen denselben Paketnamen haben und mit demselben Releaseschlüssel signiert sein. Diese Funktion ist nützlich, wenn deine App nicht alle gewünschten Geräte mit einem einzigen APK erreichen kann.

Android-Geräte können sich in verschiedenen Punkten unterscheiden und es ist für den Erfolg Ihrer App wichtig, dass Sie sie so vielen Geräten wie möglich zur Verfügung stellen. Android-Anwendungen werden in der Regel auf den meisten kompatiblen Geräten mit nur einem APK ausgeführt. Dabei werden alternative Ressourcen für verschiedene Konfigurationen (z. B. unterschiedliche Layouts für unterschiedliche Bildschirmgrößen) bereitgestellt und das Android-System wählt zur Laufzeit die entsprechenden Ressourcen für das Gerät aus. In einigen Fällen kann ein einzelnes APK jedoch nicht alle Gerätekonfigurationen unterstützen, da alternative Ressourcen die APK-Datei zu groß machen oder andere technische Probleme verhindern, dass ein einzelnes APK auf allen Geräten funktioniert.

Damit du deine App für so viele Geräte wie möglich veröffentlichen kannst, ermöglicht Google Play die Veröffentlichung mehrerer APKs unter demselben App-Eintrag. Google Play stellt dann jedes APK basierend auf der Konfigurationsunterstützung, die du in der Manifestdatei jedes APKs deklariert hast, für die entsprechenden Geräte bereit.

Wenn Sie Ihre App mit mehreren APKs veröffentlichen, haben Sie folgende Möglichkeiten:

  • Für jedes APK werden unterschiedliche OpenGL-Texturkomprimierungsformate unterstützt.
  • Unterstützt verschiedene Bildschirmgrößen und -dichten für jedes APK.
  • Unterschiedliche Gerätefunktionen für jedes APK unterstützen.
  • Unterstützen Sie mit jedem APK unterschiedliche Plattformversionen.
  • Unterstütze mit jedem APK unterschiedliche CPU-Architekturen (z. B. für ARM oder x86, wenn deine App den Android NDK verwendet).
  • Optimiere deine App für Einsteigergeräte, z. B. Geräte mit Android (Go-Edition).

Derzeit sind dies die einzigen Gerätemerkmale, die Google Play für die Veröffentlichung mehrerer APKs als dieselbe App unterstützt.

Hinweis:Informationen zum Vorbereiten und Veröffentlichen von APKs bei Google Play finden Sie im Supportartikel Releases vorbereiten und einführen.

So funktionieren mehrere APKs

Das Konzept für die Verwendung mehrerer APKs bei Google Play besteht darin, dass Sie nur einen Eintrag bei Google Play für Ihre App haben, aber unterschiedliche Geräte möglicherweise ein anderes APK herunterladen. Das bedeutet:

  • Sie verwalten nur einen Satz von Produktdetails (App-Beschreibung, Symbole, Screenshots usw.). Das bedeutet auch, dass Sie keine unterschiedlichen Preise für verschiedene APKs berechnen können.
  • Alle Nutzer sehen bei Google Play nur eine Version deiner App. Sie werden nicht durch verschiedene von dir veröffentlichte Versionen verwechselt, die für Tablets oder Smartphones gedacht sind.
  • Alle Nutzerrezensionen werden auf denselben App-Eintrag angewendet, auch wenn Nutzer auf verschiedenen Geräten unterschiedliche APKs haben.
  • Wenn Sie verschiedene APKs für verschiedene Android-Versionen für unterschiedliche API-Levels veröffentlichen und ein Nutzergerät ein Systemupdate erhält, das ihn für ein anderes von Ihnen veröffentlichtes APK qualifiziert, aktualisiert Google Play die App des Nutzers auf das APK, das für die höhere Android-Version entwickelt wurde. Alle mit der App verknüpften Systemdaten bleiben erhalten (wie bei normalen App-Updates bei Verwendung eines einzelnen APKs).

Unterstützte Filter

Welche Geräte die einzelnen APKs erhalten, wird durch Google Play-Filter bestimmt, die durch Elemente in der Manifestdatei der einzelnen APKs angegeben werden. Bei Google Play können mehrere APKs jedoch nur dann veröffentlicht werden, wenn für jedes APK Filter zur Unterstützung einer Variante der folgenden Geräteeigenschaften verwendet werden:

  • OpenGL-Texturkomprimierungsformate

    Dies basiert auf den <supports-gl-texture>-Elementen Ihrer Manifestdatei.

    Wenn Sie beispielsweise ein Spiel entwickeln, das OpenGL ES verwendet, können Sie ein APK für Geräte bereitstellen, die die ATI-Texturkomprimierung unterstützen, und ein separates APK für Geräte, die unter anderem die PowerVR-Komprimierung unterstützen.

  • Bildschirmgröße (und optional auch die Bildschirmdichte)

    Dies basiert auf dem Element <supports-screens> oder <compatible-screens> Ihrer Manifestdatei. Verwenden Sie niemals beide Elemente und nach Möglichkeit nur <supports-screens>.

    Sie können beispielsweise ein APK bereitstellen, das kleine und normale Bildschirme unterstützt, und ein anderes APK, das große und sehr große Bildschirme unterstützt. Weitere Informationen zum Generieren separater APKs basierend auf der Bildschirmgröße oder -dichte finden Sie unter Mehrere APKs erstellen.

    Beachten Sie die folgenden Best Practices für alle Bildschirmgrößen:

    • Das Android-System bietet starke Anwendungsunterstützung für alle Bildschirmkonfigurationen mit einem einzigen APK. Du solltest nur, wenn dies unbedingt erforderlich ist, mehrere APKs zur Unterstützung verschiedener Bildschirme erstellen. Folge stattdessen der Anleitung unter Unterstützung mehrerer Bildschirme, damit deine App flexibel ist und sich mit einem einzigen APK an alle Bildschirmkonfigurationen anpassen kann.
    • Standardmäßig sind alle Bildschirmgrößenattribute im Element <supports-screens> „true“, wenn sie nicht anders deklariert werden. Da jedoch das Attribut android:xlargeScreens in Android 2.3 (API-Level 9) hinzugefügt wurde, geht Google Play davon aus, dass es „false“ ist, wenn in deiner App android:minSdkVersion oder android:targetSdkVersion nicht auf „9“ oder höher festgelegt ist.
    • Du solltest in deiner Manifestdatei nicht die Elemente <supports-screens> und <compatible-screens> kombinieren. Wenn Sie beide verwenden, ist die Wahrscheinlichkeit höher, dass aufgrund von Konflikten ein Fehler auftritt. Informationen zur Entscheidung findest du unter Auf bestimmte Bildschirme verteilen. Wenn Sie nicht beides vermeiden können, beachten Sie, dass bei Konflikten in Bezug auf eine bestimmte Größe „false“ gilt.
  • Gerätefunktionen

    Dies basiert auf den <uses-feature>-Elementen Ihrer Manifestdatei.

    Du kannst beispielsweise ein APK für Geräte bereitstellen, die Multi-Touch unterstützen, und ein anderes APK für Geräte, die Multi-Touch nicht unterstützen. Eine Liste der von der Plattform unterstützten Features finden Sie in der Funktionsreferenz.

  • Android (Go-Edition)

    Wenn du ein Targeting auf Geräte mit Android (Go-Edition) vornehmen möchtest, muss dein APK <uses-feature android:name="android.hardware.ram.low" android:required="true"> deklarieren, mindestens auf API-Level 26 ausgerichtet sein und einen höheren Versionscode als das APK deiner Nicht-Go-Edition haben.

  • API-Level

    Dies basiert auf dem Element <uses-sdk> Ihrer Manifestdatei. Du kannst sowohl das android:minSdkVersion- als auch das android:maxSdkVersion-Attribut verwenden, um die Unterstützung für verschiedene API-Ebenen anzugeben.

    Du kannst deine App beispielsweise mit einem APK veröffentlichen, das die API-Level 16 bis 19 (Android 4.1.x bis 4.4.4) unterstützt und nur APIs verwendet, die ab API-Level 16 verfügbar sind, und mit einem anderen APK, das API-Level 21 und höher (Android 5.0 und höher) unterstützt. Dazu werden APIs verwendet, die seit API-Level 21 oder niedriger verfügbar sind. Informationen zum Erstellen separater APKs, die jeweils auf einen anderen Bereich von APIs ausgerichtet sind, findest du unter Produktvarianten konfigurieren.

    Wenn du diese Eigenschaft als Faktor zur Unterscheidung mehrerer APKs verwendest, muss das APK mit einem höheren Wert für android:minSdkVersion einen höheren Wert für android:versionCode haben. Dies gilt auch, wenn zwei APKs ihre Geräteunterstützung aufgrund eines anderen unterstützten Filters überschneiden. Dadurch wird sichergestellt, dass Google Play dem Nutzer ein Systemupdate für deine App anbieten kann, wenn ein Gerät ein Systemupdate erhält, da Updates auf einer Erhöhung des App-Versionscodes basieren. Diese Anforderung wird im Abschnitt Regeln für mehrere APKs genauer beschrieben.

    Du solltest android:maxSdkVersion im Allgemeinen nicht verwenden. Solange du deine App richtig mit öffentlichen APIs entwickelt hast, ist sie immer mit zukünftigen Android-Versionen kompatibel. Wenn du ein anderes APK für höhere API-Ebenen veröffentlichen möchtest, musst du trotzdem nicht die Höchstversion angeben. Denn wenn android:minSdkVersion in einem APK "16" und in einem anderen "21" ist, erhalten Geräte, die API-Level 21 oder höher unterstützen, immer das zweite APK, da der Versionscode gemäß dem vorherigen Hinweis höher ist.


  • CPU-Architektur (ABI)

    Einige native Bibliotheken bieten separate Pakete für bestimmte CPU-Architekturen oder Application Binary Interfaces (ABIs). Anstatt alle verfügbaren Bibliotheken in einem APK zu bündeln, kannst du für jede ABI ein separates APK erstellen und nur die Bibliotheken hinzufügen, die du für diese ABI brauchst. Weitere Informationen zum Generieren separater APKs basierend auf dem Ziel-ABI finden Sie unter Mehrere APKs erstellen.

Andere Manifestelemente, die Google Play-Filter aktivieren, aber oben nicht aufgeführt sind, werden wie gewohnt auf jedes APK angewendet. Bei Google Play können Sie jedoch keine separaten APKs basierend auf Varianten dieser Gerätemerkmale veröffentlichen. Daher können Sie nicht mehrere APKs veröffentlichen, wenn die oben aufgeführten Filter für jedes APK identisch sind, sich aber aufgrund anderer Merkmale im Manifest oder APK unterscheiden. Du kannst beispielsweise keine unterschiedlichen APKs bereitstellen, die sich nur in den <uses-configuration>-Eigenschaften unterscheiden.

Regeln für mehrere APKs

Bevor Sie mehrere APKs für Ihre App veröffentlichen, müssen Sie sich mit den folgenden Regeln vertraut machen:

  • Alle APKs, die Sie für dieselbe App veröffentlichen, müssen denselben Paketnamen haben und mit demselben Zertifikatsschlüssel signiert sein.
  • Jedes APK muss einen anderen Versionscode haben, der durch das Attribut android:versionCode angegeben wird.
  • Jedes APK darf nicht genau der Konfigurationsunterstützung eines anderen APKs entsprechen.

    Das heißt, jedes APK muss für mindestens einen der oben aufgeführten unterstützten Google Play-Filter eine leicht unterschiedliche Unterstützung erklären.

    Normalerweise differenzierst du deine APKs anhand bestimmter Merkmale (z. B. der unterstützten Texturkomprimierungsformate). Daher erklärt jedes APK die Unterstützung für verschiedene Geräte. Es ist jedoch in Ordnung, mehrere APKs zu veröffentlichen, bei denen sich die Unterstützung leicht überschneidet. Wenn sich zwei APKs überschneiden (sie unterstützen einige derselben Gerätekonfigurationen), erhält ein Gerät, das sich in diesen Bereich fällt, das APK mit einem höheren Versionscode (definiert durch android:versionCode).

  • Du kannst kein neues APK aktivieren, dessen Versionscode niedriger als der des APK ist, das ersetzt wird. Angenommen, Sie haben ein aktives APK für die Bildschirmgrößen „klein – normal“ mit dem Versionscode 0400. Versuchen Sie dann, es durch ein APK für dieselben Bildschirmgrößen mit dem Versionscode 0300 zu ersetzen. Dies führt zu einem Fehler, da Nutzer des vorherigen APKs die App nicht aktualisieren können.
  • Ein APK, das ein höheres API-Level erfordert, muss einen höheren Versionscode haben.

    Dies gilt nur, wenn sich die APKs entweder nur aufgrund der unterstützten API-Ebenen unterscheiden (keine anderen unterstützten Filter unterscheiden die APKs) oder wenn für die APKs ein anderer unterstützter Filter verwendet wird, es aber eine Überschneidung zwischen den APKs innerhalb dieses Filters gibt.

    Dies ist wichtig, da das Gerät eines Nutzers nur dann ein App-Update von Google Play erhält, wenn der Versionscode für das APK bei Google Play höher ist als der Versionscode des APK, das sich derzeit auf dem Gerät befindet. Wenn ein Gerät ein Systemupdate erhält, das es dann für die Installation des APK für höhere API-Ebenen qualifiziert, erhält das Gerät ein Anwendungsupdate, da sich der Versionscode erhöht.

    Hinweis:Die Größe der Erhöhung des Versionscodes spielt keine Rolle. Sie muss in der Version, die höhere API-Ebenen unterstützt, lediglich größer sein.

    Hier einige Beispiele:

    • Wenn ein APK, das Sie für API-Level 16 und höher (Android 4.1.x und höher) hochgeladen haben, den Versionscode 0400 hat, muss ein APK für API-Level 21 und höher (Android 5.0 und höher) 0401 oder höher sein. In diesem Fall ist der Filter auf API-Ebene der einzige unterstützte Filter. Daher müssen die Versionscodes steigen, je nachdem, wie viele API-Ebenen für das jeweilige APK unterstützt werden, damit Nutzer ein Update erhalten, wenn sie ein Systemupdate erhalten.
    • Wenn Sie ein APK für API-Level 16 (und höher) und für kleine Bildschirme (große Bildschirme) und ein weiteres APK für API-Ebene 21 (und höher) sowie für große Bildschirme mit großen Bildschirmen haben, müssen sich die Versionscodes entsprechend den API-Ebenen erhöhen. In diesem Fall wird der API-Level-Filter verwendet, um die einzelnen APKs zu unterscheiden, ebenso wie die Bildschirmgröße. Da sich die Bildschirmgrößen überschneiden (beide APKs große Bildschirme unterstützen), müssen die Versionscodes noch geordnet sein. Dadurch wird sichergestellt, dass ein Gerät mit großem Bildschirm, das ein Systemupdate auf API-Level 21 erhält, ein Update für das zweite APK erhält.
    • Wenn Sie ein APK für API-Level 16 (und höher) und kleine, normale Bildschirme sowie ein anderes APK für API-Ebene 21 und höher sowie für große, sehr große Bildschirme haben, müssen die Versionscodes entsprechend den API-Ebenen nicht erhöht werden. Da es keine Überschneidung innerhalb des Bildschirmgrößenfilters gibt, gibt es keine Geräte, die potenziell zwischen diesen beiden APKs wechseln könnten. Daher müssen die Versionscodes nicht von der niedrigeren auf die höhere API-Ebene erhöht werden.
    • Wenn Sie ein APK für API-Level 16 (oder höher) und ARMv7-CPUs, ein anderes APK für API-Level 21 (und höher) und ARMv5TE-CPUs haben, müssen sich die Versionscodes entsprechend den API-Levels erhöhen. In diesem Fall wird der Filter auf API-Ebene verwendet, um die einzelnen APKs zu unterscheiden. Dies gilt jedoch auch für die CPU-Architektur. Da ein APK mit ARMv5TE-Bibliotheken mit Geräten mit ARMv7-CPU kompatibel ist, überschneiden sich die APKs in dieser Eigenschaft. Daher muss der Versionscode für das APK, das API-Level 21 und höher unterstützt, höher sein. Dadurch wird sichergestellt, dass ein Gerät mit einer ARMv7-CPU, die ein Systemupdate auf API-Level 21 erhält, ein Update für das zweite APK erhält, das für API-Level 21 entwickelt wurde. Da diese Art von Update jedoch dazu führt, dass das ARMv7-Gerät ein APK verwendet, das nicht vollständig für die CPU dieses Geräts optimiert ist, sollten Sie ein APK sowohl für die ARMv5TE- als auch für die ARMv7-Architektur auf jeder API-Ebene bereitstellen, um die App-Leistung auf jeder CPU zu optimieren. Hinweis:Dies gilt nur für den Vergleich von APKs mit den Bibliotheken ARMv5TE und ARMv7 und nicht für den Vergleich anderer nativer Bibliotheken.

Andernfalls wird in der Google Play Console ein Fehler angezeigt, wenn Sie Ihre APKs aktivieren. Sie können Ihre App erst dann veröffentlichen, wenn Sie den Fehler behoben haben.

Wenn Sie Ihre APKs aktivieren, können andere Konflikte auftreten, die aber zu Warnungen und nicht zu Fehlern führen. Warnungen können folgende Ursachen haben:

  • Wenn Sie ein APK so ändern, dass die Unterstützung für die Eigenschaften eines Geräts „verkleinert“ wird und keine anderen APKs die Geräte unterstützen, die außerhalb des unterstützten Bereichs liegen. Wenn ein APK beispielsweise derzeit kleine und normale Bildschirme unterstützt und Sie es so ändern, dass nur kleine Bildschirme unterstützt werden, haben Sie die Anzahl der unterstützten Geräte reduziert und Ihre App wird für einige Geräte nicht mehr bei Google Play angezeigt. Sie können dies beheben, indem Sie ein weiteres APK hinzufügen, das Bildschirme in normaler Größe unterstützt, sodass alle zuvor unterstützten Geräte weiterhin unterstützt werden.
  • Wenn es „Überlappungen“ zwischen zwei oder mehr APKs gibt. Wenn ein APK beispielsweise die Bildschirmgrößen „klein“, „normal“ und „groß“ unterstützt, während ein anderes APK die Größen groß und sehr groß, liegt eine Überschneidung vor, da beide APKs große Bildschirme unterstützen. Wenn Sie dies nicht beheben, erhalten Geräte, die für beide APKs geeignet sind (im Beispiel Geräte mit großem Bildschirm), das APK mit dem höchsten Versionscode.

    Hinweis:Wenn Sie separate APKs für verschiedene CPU-Architekturen erstellen, sollten Sie beachten, dass sich ein APK für ARMv5TE mit einem APK für ARMv7 überschneidet. Das heißt, ein APK, das für ARMv5TE entwickelt wurde, ist mit einem ARMv7-Gerät kompatibel, umgekehrt aber nicht. Ein APK, das nur die ARMv7-Bibliotheken enthält, ist nicht mit einem ARMv5TE-Gerät kompatibel.

Wenn solche Konflikte auftreten, wird eine Warnmeldung angezeigt. Sie können Ihre Anwendung aber trotzdem veröffentlichen.

Mehrere APKs erstellen

Wenn Sie sich für die Veröffentlichung mehrerer APKs entschieden haben, müssen Sie wahrscheinlich für jedes APK, das Sie veröffentlichen möchten, separate Android-Projekte erstellen, damit Sie sie separat entwickeln können. Sie können dies tun, indem Sie einfach Ihr vorhandenes Projekt duplizieren und ihm einen neuen Namen geben. Alternativ können Sie auch ein Build-System verwenden, das je nach Build-Konfiguration verschiedene Ressourcen wie Texturen ausgeben kann.

Tipp:Um das Duplizieren großer Teile Ihres Anwendungscodes zu vermeiden, können Sie ein Bibliotheksprojekt verwenden. Ein Bibliotheksprojekt enthält freigegebenen Code und Ressourcen, die Sie in Ihre tatsächlichen Anwendungsprojekte einbinden können.

Wenn Sie mehrere Projekte für dieselbe App erstellen, sollten Sie jedes Projekt mit einem Namen versehen, der die für das APK geltenden Geräteeinschränkungen angibt. So können Sie sie leicht identifizieren. Beispielsweise könnte „HelloWorld_21“ ein guter Name für eine Anwendung sein, die für API-Level 21 und höher entwickelt wurde.

Hinweis:Alle APKs, die Sie für dieselbe App veröffentlichen, müssen denselben Paketnamen und mit demselben Zertifikatsschlüssel signiert sein. Informieren Sie sich außerdem über die Regeln für mehrere APKs.

Versionscodes zuweisen

Jedes APK für dieselbe App muss einen eindeutigen Versionscode haben, der durch das Attribut android:versionCode angegeben wird. Beim Veröffentlichen mehrerer APKs müssen Sie beim Zuweisen von Versionscodes vorsichtig sein, da sich die einzelnen APKs unterscheiden müssen, aber in einigen Fällen je nach den von den einzelnen APKs unterstützten Konfigurationen in einer bestimmten Reihenfolge definiert werden müssen oder sollten.

Versionscodes bestellen

Ein APK, das ein höheres API-Level erfordert, muss in der Regel einen höheren Versionscode haben. Wenn Sie beispielsweise zwei APKs erstellen, um unterschiedliche API-Ebenen zu unterstützen, muss das APK für die höheren API-Ebenen den höheren Versionscode haben. Dadurch wird sichergestellt, dass Nutzer, wenn ein Gerät ein Systemupdate erhält, das sie zur Installation des APK für höhere API-Levels berechtigt, eine Benachrichtigung zum Aktualisieren der App erhält. Weitere Informationen dazu, wie diese Anforderung gilt, finden Sie oben im Abschnitt Regeln für mehrere APKs.

Sie sollten auch berücksichtigen, wie sich die Reihenfolge der Versionscodes darauf auswirken kann, welches APK Ihre Nutzer erhalten. Dies kann beispielsweise auf Überschneidungen bei verschiedenen APKs oder auf zukünftige Änderungen zurückzuführen sein, die Sie an Ihren APKs vornehmen könnten.

Wenn Sie beispielsweise verschiedene APKs haben, die auf der Bildschirmgröße basieren, z. B. eines für die Größe „klein“ – „normal“ und eines für „groß“ – „XL“, aber planen Sie einen Zeitpunkt ein, in dem Sie die APKs in ein großes APK und eins für „normal“ (XL) ändern werden. Dann sollten Sie den Versionscode für das große APK der Größe XL erhöhen. Auf diese Weise erhält ein Gerät mit normaler Größe das entsprechende Update, wenn Sie die Änderung vornehmen, da der Versionscode vom vorhandenen APK auf das neue APK erhöht wird, das das Gerät jetzt unterstützt.

Beachten Sie auch beim Erstellen mehrerer APKs, die sich aufgrund der Unterstützung verschiedener OpenGL-Texturkomprimierungsformate unterscheiden, dass viele Geräte mehrere Formate unterstützen. Da ein Gerät das APK mit dem höchsten Versionscode erhält, wenn es eine Überschneidung zwischen zwei APKs gibt, sollten Sie die Versionscodes unter Ihren APKs sortieren, sodass das APK mit dem bevorzugten Komprimierungsformat den höchsten Versionscode hat. Sie können beispielsweise separate Builds für Ihre Anwendung mit den Komprimierungsformaten PVRTC, ATITC und ETC1 durchführen. Wenn Sie diese Formate in genau dieser Reihenfolge bevorzugen, sollte das APK, das PVRTC verwendet, den höchsten Versionscode haben, das APK, das ATITC verwendet, einen niedrigeren Versionscode und die Version mit ETC1 den niedrigsten Versionscode hat. Wenn also ein Gerät sowohl PVRTC als auch ETC1 unterstützt, erhält es das APK mit PVRTC, da es den höchsten Versionscode hat.

Falls der Google Play Store das richtige APK für die Installation auf einem Zielgerät nicht ermitteln kann, können Sie auch ein universelles APK erstellen, das Ressourcen für alle unterstützten Gerätevarianten enthält. Wenn du ein universelles APK angibst, solltest du ihm die niedrigste versionCode zuweisen. Da der Google Play Store die Version deiner App installiert, die sowohl mit dem Zielgerät kompatibel ist als auch die höchste versionCode hat, wird durch die Zuweisung einer niedrigeren versionCode zum universellen APK sichergestellt, dass der Google Play Store versucht, eines deiner anderen APKs zu installieren, bevor auf das größere universelle APK zurückgreift.

Versionscode-Schema verwenden

Damit verschiedene APKs ihre Versionscodes unabhängig von anderen aktualisieren können, z. B. wenn Sie einen Fehler in nur einem APK beheben und nicht alle APKs aktualisieren müssen, sollten Sie ein Schema für Ihre Versionscodes verwenden, das genügend Platz zwischen den einzelnen APKs bietet, damit Sie den Code in einem einzelnen APK erhöhen können, ohne die anderen APKs zu erhöhen. Sie sollten auch den tatsächlichen Versionsnamen in den Code aufnehmen (d. h. die für den Nutzer sichtbare Version, die android:versionName zugewiesen ist), damit Sie den Versionscode und den Versionsnamen einfach zuordnen können.

Hinweis:Wenn Sie den Versionscode für ein APK erhöhen, fordert Google Play die Nutzer der vorherigen Version auf, die App zu aktualisieren. Um unnötige Aktualisierungen zu vermeiden, sollten Sie den Versionscode für APKs, die keine Änderungen enthalten, daher nicht erhöhen.

Wir empfehlen die Verwendung eines Versionscodes mit mindestens 7 Ziffern: Ganzzahlen für die unterstützten Konfigurationen sind in den Bits höherer Ordnung und der Versionsname (aus android:versionName) in den Bits niedrigerer Reihenfolge. Wenn der Name der App-Version beispielsweise 3.1.0 lautet, würden die Versionscodes für ein APK mit API-Level 4 und ein APK mit API-Level 11 in etwa 0400310 bzw. 1100310 lauten. Die ersten beiden Ziffern sind für das API-Level 4 bzw. 11 reserviert, die mittleren zwei Ziffern sind entweder für Bildschirmgrößen oder GL-Texturformate (in diesen Beispielen nicht verwendet) und die letzten drei Ziffern für den Versionsnamen der Anwendung (3.1.0). Abbildung 1 zeigt zwei Beispiele, die basierend auf der Plattformversion (API-Level) und der Bildschirmgröße aufgeteilt wurden.

Abbildung 1: Ein empfohlenes Schema für Ihre Versionscodes, bei dem die ersten beiden Ziffern für die API-Ebene, die zweite und dritte Ziffern für die minimale und maximale Bildschirmgröße (1–4 für jede der vier Größen) oder die Texturformate und die letzten drei Ziffern für die App-Version verwendet werden

Dieses Schema für Versionscodes ist nur ein Vorschlag, wie Sie ein Muster erstellen sollten, das beim Weiterentwicklung Ihrer Anwendung skalierbar ist. Insbesondere zeigt dieses Schema keine Lösung für die Identifizierung verschiedener Texturkomprimierungsformate. Eine Option könnte darin bestehen, eine eigene Tabelle zu definieren, die für jedes der verschiedenen Komprimierungsformate, die Ihre Anwendung unterstützt, eine andere Ganzzahl angibt (z. B. kann 1 ETC1 entsprechen, 2 ATITC usw.).

Sie können jedes beliebige Schema verwenden. Sie sollten jedoch sorgfältig überlegen, wie die Versionscodes zukünftiger Versionen Ihrer Anwendung erhöht werden müssen und wie Geräte Updates erhalten können, wenn sich entweder die Gerätekonfiguration ändert (z. B. aufgrund eines Systemupdates) oder wenn Sie die Konfigurationsunterstützung für eines oder mehrere der APKs ändern.

Zurück
Verschiedene Pixeldichten unterstützen
Weiter
Mehrere APKs für verschiedene API-Ebenen erstellen