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 und liefert Google Play automatisch optimierte APKs für die Gerätekonfiguration jedes Nutzers, sodass nur der Code und die Ressourcen heruntergeladen werden, die zum Ausführen Ihrer App erforderlich sind. Die Veröffentlichung mehrerer APKs ist nützlich, wenn Sie Ihre App nicht bei Google Play veröffentlichen, aber jedes APK selbst erstellen, signieren und verwalten müssen.

Die Unterstützung mehrerer APKs ist eine Funktion bei Google Play, mit der Sie verschiedene APKs für Ihre Anwendung 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 Release-Schlüssel signiert sein. Diese Funktion ist nützlich, wenn Ihre App nicht alle gewünschten Geräte mit einem einzigen APK erreichen kann.

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

Damit Sie Ihre App für möglichst viele Geräte veröffentlichen können, können Sie bei Google Play mehrere APKs im selben App-Eintrag veröffentlichen. Google Play stellt dann jedes APK auf den entsprechenden Geräten bereit, basierend auf der Konfigurationsunterstützung, die Sie in der Manifestdatei jedes APK angegeben haben.

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

  • Unterstützen Sie mit jedem APK unterschiedliche OpenGL-Texturkomprimierungsformate.
  • Unterstützen Sie mit jedem APK unterschiedliche Bildschirmgrößen und -dichten.
  • Mit jedem APK unterschiedliche Gerätefunktionen unterstützen.
  • Unterstützen Sie mit jedem APK unterschiedliche Plattformversionen.
  • Unterstützen Sie mit jedem APK unterschiedliche CPU-Architekturen, z. B. ARM oder x86, wenn Ihre App das Android-NDK verwendet.
  • Optimieren Sie Ihre App für Einstiegsgeräte, z. B. solche mit Android (Go-Edition).

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

Hinweis:Informationen zum Vorbereiten und Veröffentlichen von APKs bei Google Play finden Sie im Hilfeartikel Releases vorbereiten und freigeben.

Funktionsweise mehrerer APKs

Bei der Verwendung mehrerer APKs bei Google Play haben Sie nur einen Eintrag für Ihre App bei Google Play, aber auf verschiedenen Geräten wird möglicherweise ein anderes APK heruntergeladen. Das bedeutet Folgendes:

  • Sie verwalten nur eine Reihe von Produktdetails (App-Beschreibung, Symbole, Screenshots usw.). Das bedeutet auch, dass Sie nicht für verschiedene APKs unterschiedliche Preise verlangen können.
  • Alle Nutzer sehen bei Google Play nur eine Version Ihrer App. So werden sie nicht durch verschiedene Versionen verwirrt, die Sie möglicherweise veröffentlicht haben und die „für Tablets“ oder „für Smartphones“ gedacht sind.
  • Alle Nutzerrezensionen werden auf denselben App-Eintrag angewendet, auch wenn Nutzer auf verschiedenen Geräten möglicherweise unterschiedliche APKs haben.
  • Wenn Sie verschiedene APKs für verschiedene Android-Versionen (für verschiedene API-Levels) veröffentlichen, aktualisiert Google Play die App des Nutzers auf das APK für die höhere Android-Version, wenn das Gerät des Nutzers ein Systemupdate erhält, das die Installation eines anderen von Ihnen veröffentlichten APKs ermöglicht. Alle mit der Anwendung verknüpften Systemdaten bleiben erhalten (wie bei normalen App-Aktualisierungen bei Verwendung eines einzelnen APKs).

Unterstützte Filter

Welche Geräte jedes APK erhalten, wird durch Google Play-Filter bestimmt, die durch Elemente in der Manifestdatei jedes APKs angegeben werden. Bei Google Play können Sie jedoch nur dann mehrere APKs veröffentlichen, wenn jedes APK Filter verwendet, um eine Variante der folgenden Gerätemerkmale zu unterstützen:

  • OpenGL-Texturkomprimierungsformate

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

    Wenn Sie beispielsweise ein Spiel mit OpenGL ES entwickeln, 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.

  • Displaygröße (und optional Bildschirmdichte)

    Das hängt vom Element <supports-screens> oder <compatible-screens> in Ihrer Manifestdatei ab. Sie sollten nie beide Elemente verwenden und nach Möglichkeit nur <supports-screens>.

    Sie können beispielsweise ein APK bereitstellen, das Bildschirme in kleiner und normaler Größe unterstützt, und ein anderes APK, das große und extra große Bildschirme unterstützt. Weitere Informationen zum Generieren separater APKs basierend auf Bildschirmgröße oder ‑dichte finden Sie unter Mehrere APKs erstellen.

    Beachten Sie die folgenden Best Practices, um alle Bildschirmgrößen zu unterstützen:

    • Das Android-System bietet eine umfassende Unterstützung für Anwendungen, die alle Bildschirmkonfigurationen mit einem einzigen APK unterstützen. Sie sollten nur dann mehrere APKs zur Unterstützung verschiedener Bildschirme erstellen, wenn es unbedingt erforderlich ist. Folgen Sie stattdessen der Anleitung unter Mehrere Bildschirme unterstützen, damit Ihre Anwendung flexibel ist und sich mit einem einzigen APK an alle Bildschirmkonfigurationen anpassen kann.
    • Standardmäßig haben alle Bildschirmgrößenattribute im Element <supports-screens> den Wert „wahr“, sofern Sie nichts anderes angeben. Da das Attribut android:xlargeScreens jedoch erst in Android 2.3 (API-Level 9) hinzugefügt wurde, geht Google Play davon aus, dass es „false“ (falsch) ist, wenn Ihre App weder android:minSdkVersion noch android:targetSdkVersion auf „9“ oder höher festlegt.
    • Sie sollten in Ihrer Manifestdatei weder <supports-screens>- noch <compatible-screens>-Elemente verwenden. Wenn Sie beide verwenden, erhöht sich die Wahrscheinlichkeit, dass aufgrund von Konflikten zwischen ihnen ein Fehler auftritt. Informationen dazu, welche Sie verwenden sollten, finden Sie unter An bestimmte Bildschirme senden. Wenn Sie beide verwenden müssen, beachten Sie, dass bei Konflikten bei der Vereinbarung einer bestimmten Größe „false“ verwendet wird.

  • Gerätefunktionsgruppen

    Dies richtet sich nach den <uses-feature>-Elementen Ihrer Manifestdatei.

    Sie können beispielsweise ein APK für Geräte bereitstellen, die Multitouch unterstützen, und ein anderes APK für Geräte, die Multitouch nicht unterstützen. Eine Liste der von der Plattform unterstützten Funktionen finden Sie unter Referenz zu Funktionen.

  • Android (Go-Version)

    Wenn Sie Ihre App auf Geräte mit Android (Go-Edition) ausrichten möchten, muss Ihr APK <uses-feature android:name="android.hardware.ram.low" android:required="true"> angeben, auf mindestens API-Level 26 ausgerichtet sein und einen höheren Versionscode als das APK der Nicht-Go-Version haben.

  • API-Level

    Dieser Wert basiert auf dem <uses-sdk>-Element Ihrer Manifestdatei. Sie können sowohl das Attribut android:minSdkVersion als auch das Attribut android:maxSdkVersion verwenden, um die Unterstützung für verschiedene API-Ebenen anzugeben.

    Sie können Ihre App beispielsweise mit einem APK veröffentlichen, das die API-Levels 16 bis 19 (Android 4.1.x bis 4.4.4) unterstützt – dabei werden nur APIs verwendet, die seit API-Level 16 oder niedriger verfügbar sind – und einem anderen APK, das die API-Levels 21 und höher (Android 5.0 und höher) unterstützt – dabei werden nur APIs verwendet, die seit API-Level 21 oder niedriger verfügbar sind. Informationen zum Erstellen separater APKs, die jeweils auf einen anderen API-Bereich ausgerichtet sind, finden Sie unter Produktvarianten konfigurieren.

    Wenn Sie diese Eigenschaft als Faktor zum Unterscheiden mehrerer APKs verwenden, muss das APK mit dem höheren Wert für android:minSdkVersion einen höheren Wert für android:versionCode haben. Das gilt auch, wenn sich die Geräteunterstützung zweier APKs aufgrund eines anderen unterstützten Filters überschneidet. So kann Google Play Nutzern ein Update für Ihre App anbieten, wenn auf einem Gerät ein Systemupdate installiert wird, da Updates auf einer Erhöhung des App-Versionscodes basieren. Diese Anforderung wird im Abschnitt Regeln für mehrere APKs unten näher beschrieben.

    Sie sollten android:maxSdkVersion im Allgemeinen vermeiden, da Ihre App, sofern Sie sie richtig mit öffentlichen APIs entwickelt haben, immer mit zukünftigen Android-Versionen kompatibel ist. Wenn Sie ein anderes APK für höhere API-Levels veröffentlichen möchten, müssen Sie die maximale Version nicht angeben. Wenn android:minSdkVersion in einem APK "16" und in einem anderen "21" ist, erhalten Geräte mit API-Level 21 oder höher immer das zweite APK, da sein Versionscode wie in der vorherigen Anmerkung 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 verpacken, können Sie für jedes ABI ein separates APK erstellen und nur die Bibliotheken einschließen, die Sie für dieses ABI benötigen. 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 nicht oben aufgeführt sind, werden weiterhin wie gewohnt auf jedes APK angewendet. Bei Google Play ist es jedoch nicht zulässig, separate APKs auf Grundlage von Varianten dieser Gerätemerkmale zu veröffentlichen. Sie können also nicht mehrere APKs veröffentlichen, wenn die oben aufgeführten Filter für jedes APK identisch sind, sich die APKs aber aufgrund anderer Merkmale im Manifest oder APK unterscheiden. Sie können beispielsweise keine verschiedenen 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 die folgenden Regeln beachten:

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

    Das bedeutet, dass jedes APK für mindestens einen der oben aufgeführten unterstützten Google Play-Filter eine leicht unterschiedliche Unterstützung angeben muss.

    Normalerweise unterscheiden Sie Ihre APKs anhand einer bestimmten Eigenschaft (z. B. der unterstützten Texturkomprimierungsformate). Daher wird in jedem APK die Unterstützung für unterschiedliche Geräte deklariert. Es ist jedoch in Ordnung, mehrere APKs zu veröffentlichen, deren Unterstützung sich geringfügig überschneidet. Wenn sich zwei APKs überschneiden (d. h., sie unterstützen einige derselben Gerätekonfigurationen), erhält ein Gerät, das in diesen Bereich fällt, das APK mit dem höheren Versionscode (definiert durch android:versionCode).

  • Sie können kein neues APK mit einem niedrigeren Versionscode als das APK aktivieren, das es ersetzt. Angenommen, Sie haben ein aktives APK für Bildschirmgrößen „Klein“ bis „Normal“ mit dem Versionscode 0400. Versuchen Sie, es durch ein APK für dieselben Bildschirmgrößen mit dem Versionscode 0300 zu ersetzen. Dadurch wird ein Fehler ausgegeben, da Nutzer des vorherigen APKs die Anwendung nicht aktualisieren können.
  • Ein APK, für das ein höheres API-Level erforderlich ist, muss einen höheren Versionscode haben.

    Das ist nur dann der Fall, wenn sich die APKs nur anhand der unterstützten API-Ebenen unterscheiden (keine anderen unterstützten Filter unterscheiden die APKs voneinander) oder wenn für die APKs ein anderer unterstützter Filter verwendet wird, sich die APKs innerhalb dieses Filters aber überschneiden.

    Das ist wichtig, da das Gerät eines Nutzers nur dann ein App-Update von Google Play erhält, wenn der Versionscode der APK bei Google Play höher ist als der Versionscode der APK, die sich derzeit auf dem Gerät befindet. So wird sichergestellt, dass ein Gerät, das ein Systemupdate erhält, das es zur Installation des APK für höhere API-Levels berechtigt, ein App-Update erhält, da der Versionscode erhöht wird.

    Hinweis:Die Größe der Erhöhung des Versionscodes ist irrelevant. Er muss in der Version, die höhere API-Ebenen unterstützt, einfach höher sein.

    Hier einige Beispiele:

    • Wenn ein von Ihnen für API-Level 16 und höher (Android 4.1.x und höher) hochgeladenes APK einen Versionscode von 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 die API-Ebene der einzige unterstützte Filter. Daher müssen die Versionscodes in Abhängigkeit von der API-Ebene für jedes APK erhöht werden, damit Nutzer ein Update erhalten, wenn sie ein Systemupdate erhalten.
    • Wenn Sie ein APK für API-Level 16 (und höher) und kleine bis große Bildschirme und ein weiteres APK für API-Level 21 (und höher) und große bis sehr große Bildschirme haben, müssen die Versionscodes in Abhängigkeit von den API-Levels steigen. In diesem Fall wird zum Unterscheiden der einzelnen APKs sowohl der Filter auf API-Ebene als auch die Bildschirmgröße verwendet. Da sich die Bildschirmgrößen überschneiden (beide APKs unterstützen große Bildschirme), müssen die Versionscodes trotzdem in Ordnung sein. So wird sichergestellt, dass ein Gerät mit großem Bildschirm, das ein Systemupdate auf API-Level 21 erhält, auch ein Update für die zweite APK erhält.
    • Wenn Sie ein APK für API-Level 16 (und höher) und kleine bis normale Bildschirme und ein weiteres APK für API-Level 21 (und höher) und große bis sehr große Bildschirme haben, müssen die Versionscodes nicht in Korrelation mit den API-Levels erhöht werden. Da es keine Überschneidungen 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 vom niedrigeren API-Level zum höheren API-Level erhöht werden.
    • Wenn Sie ein APK für API-Level 16 (und höher) und ARMv7-CPUs und ein weiteres APK für API-Level 21 (und höher) und ARMv5TE-CPUs haben, müssen die Versionscodes in Korrelation mit den API-Levels erhöht werden. In diesem Fall wird jedes APK nicht nur anhand des Filters auf API-Ebene, sondern auch anhand der CPU-Architektur unterschieden. Da ein APK mit ARMv5TE-Bibliotheken mit Geräten mit einer 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. So wird sichergestellt, dass ein Gerät mit einer ARMv7-CPU, das ein Systemupdate auf API-Level 21 erhält, auch ein Update für das zweite APK erhält, das für API-Level 21 entwickelt wurde. Da bei dieser Art von Update jedoch ein APK auf dem ARMv7-Gerät verwendet wird, das nicht vollständig für die CPU des Geräts optimiert ist, sollten Sie auf jeder API-Ebene ein APK sowohl für die ARMv5TE- als auch für die ARMv7-Architektur bereitstellen, um die App-Leistung auf jeder CPU zu optimieren. Hinweis:Dies gilt nur, wenn APKs mit den ARMv5TE- und ARMv7-Bibliotheken verglichen werden, nicht bei anderen nativen Bibliotheken.

Wenn Sie die oben genannten Regeln nicht einhalten, wird bei der Aktivierung Ihrer APKs in der Google Play Console ein Fehler angezeigt. Sie können Ihre App erst veröffentlichen, wenn Sie den Fehler behoben haben.

Es kann auch andere Konflikte beim Aktivieren Ihrer APKs geben, die jedoch eher zu Warnungen als zu Fehlern führen. Warnungen können folgende Ursachen haben:

  • Wenn Sie ein APK so ändern, dass die Unterstützung für die Merkmale eines Geräts „verringert“ wird und keine anderen APKs die Geräte unterstützen, die dann nicht mehr in den unterstützten Bereich fallen. Wenn ein APK beispielsweise derzeit Bildschirme in kleiner und normaler Größe unterstützt und Sie die Unterstützung auf nur kleine Bildschirme beschränken, wird die Anzahl der unterstützten Geräte verringert und auf einigen Geräten wird Ihre App bei Google Play nicht mehr angezeigt. Sie können das Problem beheben, indem Sie ein weiteres APK hinzufügen, das Bildschirme in normaler Größe unterstützt, damit alle zuvor unterstützten Geräte weiterhin unterstützt werden.
  • Wenn es Überschneidungen 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ß“ unterstützt, gibt es eine Überschneidung, da beide APKs große Bildschirme unterstützen. Wenn Sie das Problem nicht beheben, erhalten Geräte, die für beide APKs infrage kommen (im Beispiel Geräte mit großem Bildschirm), das APK mit dem höchsten Versionscode.

    Hinweis:Wenn Sie separate APKs für unterschiedliche CPU-Architekturen erstellen, beachten Sie, 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, aber nicht umgekehrt. Ein APK mit nur den ARMv7-Bibliotheken ist nicht mit einem ARMv5TE-Gerät kompatibel.

In diesem Fall wird eine Warnung angezeigt, Sie können Ihre App aber trotzdem veröffentlichen.

Mehrere APKs erstellen

Wenn Sie mehrere APKs veröffentlichen möchten, 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. Dazu können Sie einfach Ihr vorhandenes Projekt duplizieren und ihm einen neuen Namen geben. Alternativ können Sie ein Build-System verwenden, das je nach Build-Konfiguration unterschiedliche Ressourcen wie Texturen ausgeben kann.

Tipp:Eine Möglichkeit, große Teile des Anwendungscodes zu vermeiden, ist die Verwendung eines Bibliotheksprojekts. Ein Bibliotheksprojekt enthält gemeinsamen Code und Ressourcen, die Sie in Ihre eigentlichen Anwendungsprojekte einbinden können.

Wenn Sie mehrere Projekte für dieselbe Anwendung erstellen, sollten Sie jedem Projekt einen Namen geben, der die Geräteeinschränkungen angibt, die für die APK gelten sollen. So können Sie sie leicht identifizieren. „HelloWorld_21“ wäre beispielsweise ein guter Name für eine Anwendung, die für API-Level 21 und höher entwickelt wurde.

Hinweis:Alle APKs, die Sie für dieselbe Anwendung veröffentlichen, müssen denselben Paketnamen haben und mit demselben Zertifikatschlüssel signiert sein. Sie müssen auch alle Regeln für mehrere APKs kennen.

Versionscodes zuweisen

Jedes APK für dieselbe Anwendung muss einen eindeutigen Versionscode haben, der durch das android:versionCode-Attribut angegeben wird. Achten Sie beim Veröffentlichen mehrerer APKs darauf, Versionscodes zuzuweisen, da sie alle unterschiedlich sein müssen. In einigen Fällen müssen oder sollten sie jedoch in einer bestimmten Reihenfolge definiert werden, je nachdem, welche Konfigurationen die einzelnen APKs unterstützen.

Versionscodes bestellen

Ein APK, für das ein höheres API-Level erforderlich ist, muss in der Regel einen höheren Versionscode haben. Wenn Sie beispielsweise zwei APKs zur Unterstützung verschiedener API-Ebenen erstellen, muss das APK für die höheren API-Ebenen den höheren Versionscode haben. So wird sichergestellt, dass Nutzer, deren Gerät ein Systemupdate erhält, durch das es die Installation des APKs für höhere API-Levels unterstützt, eine Benachrichtigung zum Aktualisieren der App erhalten. Weitere Informationen dazu, wie diese Anforderung angewendet wird, finden Sie im Abschnitt oben unter Regeln für mehrere APKs.

Berücksichtigen Sie auch, wie sich die Reihenfolge der Versionscodes auf die APKs auswirken kann, die Ihre Nutzer erhalten, entweder aufgrund von Überschneidungen bei der Abdeckung verschiedener APKs oder aufgrund zukünftiger Änderungen, die Sie an Ihren APKs vornehmen.

Wenn Sie beispielsweise unterschiedliche APKs für verschiedene Bildschirmgrößen haben, z. B. eines für „klein“ – „normal“ und eines für „groß“ – „sehr groß“, aber davon ausgehen, dass Sie die APKs in Zukunft in ein APK für „klein“ und ein APK für „normal“ – „sehr groß“ umwandeln werden, sollten Sie den Versionscode für das APK „groß“ – „sehr groß“ höher ansetzen. So erhält ein Gerät mit normaler Größe das entsprechende Update, wenn Sie die Änderung vornehmen, da der Versionscode vom vorhandenen APK zum neuen APK erhöht wird, das das Gerät jetzt unterstützt.

Wenn Sie mehrere APKs erstellen, die sich aufgrund der Unterstützung verschiedener OpenGL-Texturkomprimierungsformate unterscheiden, beachten Sie, dass viele Geräte mehrere Formate unterstützen. Da ein Gerät das APK mit dem höchsten Versionscode erhält, wenn sich die Abdeckung von zwei APKs überschneidet, sollten Sie die Versionscodes Ihrer APKs so anordnen, dass das APK mit dem bevorzugten Komprimierungsformat den höchsten Versionscode hat. Sie können beispielsweise separate Builds für Ihre App mit den Komprimierungsformaten PVRTC, ATITC und ETC1 ausführen. Wenn Sie diese Formate in genau dieser Reihenfolge bevorzugen, sollte das APK mit PVRTC den höchsten Versionscode haben, das APK mit ATITC einen niedrigeren Versionscode und die Version mit ETC1 den niedrigsten. Wenn ein Gerät also sowohl PVRTC als auch ETC1 unterstützt, erhält es die APK mit PVRTC, da diese die höchste Versionsnummer hat.

Falls der Google Play Store das richtige APK für ein Zielgerät nicht finden kann, sollten Sie auch ein universelles APK erstellen, das Ressourcen für alle unterstützten Gerätevarianten enthält. Wenn Sie ein universelles APK bereitstellen, sollten Sie ihm den niedrigsten versionCode zuweisen. Da im Google Play Store die Version Ihrer App installiert wird, die sowohl mit dem Zielgerät kompatibel ist als auch die höchste versionCode hat, wird durch die Zuweisung einer niedrigeren versionCode für das universelle APK sichergestellt, dass der Google Play Store versucht, eines Ihrer anderen APKs zu installieren, bevor er auf das größere universelle APK zurückgreift.

Versionscodeschema verwenden

Damit die Versionscodes verschiedener APKs unabhängig voneinander aktualisiert werden können (z. B. wenn Sie einen Fehler nur in einem APK beheben und nicht alle APKs aktualisieren müssen), sollten Sie ein Schema für Ihre Versionscodes verwenden, das genügend Spielraum zwischen den einzelnen APKs bietet, damit Sie den Code in einem erhöhen können, ohne dass eine Erhöhung in anderen erforderlich ist. Sie sollten auch den tatsächlichen Versionsnamen in den Code aufnehmen, also die für android:versionName zugewiesene sichtbare Version, damit Sie den Versionscode und den Versionsnamen leicht zuordnen können.

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

Wir empfehlen einen Versionscode mit mindestens sieben Ziffern: Ganzzahlen, die die unterstützten Konfigurationen darstellen, befinden sich in den Bits höherer Ordnung und der Versionsname (von android:versionName) in den Bits niedrigerer Ordnung. Wenn der Name der App-Version beispielsweise 3.1.0 lautet, lauten die Versionscodes für ein APK mit API-Level 4 und ein APK mit API-Level 11 beispielsweise 0400310 und 1100310. Die ersten beiden Ziffern sind für das API-Level reserviert (4 und 11), die mittleren beiden Ziffern stehen 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 sowohl nach der Plattformversion (API-Ebene) als auch nach der Bildschirmgröße unterteilt sind.

Abbildung 1: Ein vorgeschlagenes Schema für Ihre Versionscodes, bei dem die ersten beiden Ziffern für das API-Level, die zweite und dritte Ziffer für die minimale und maximale Bildschirmgröße (1–4 für jede der vier Größen) oder für 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 festlegen sollten, das mit der Weiterentwicklung Ihrer Anwendung skalierbar ist. Insbesondere wird mit diesem Schema keine Lösung zur Identifizierung verschiedener Texturkomprimierungsformate demonstriert. Eine Möglichkeit besteht darin, eine eigene Tabelle zu definieren, in der für jedes der verschiedenen Komprimierungsformate, die von Ihrer Anwendung unterstützt werden, eine andere Ganzzahl angegeben wird. Beispiel: „1“ könnte ETC1 und „2“ ATITC entsprechen usw.

Sie können jedes beliebige Schema verwenden, sollten aber sorgfältig überlegen, wie die Versionscodes für zukünftige Versionen Ihrer App 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 Sie die Konfigurationsunterstützung für eines oder mehrere der APKs ändern.

Weiter
Mehrere APKs für verschiedene API-Ebenen erstellen