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.
Wenn Sie bei der Entwicklung Ihrer Android-App die Vorteile mehrerer APKs bei Google Play nutzen möchten, ist es wichtig, von Anfang an einige Best Practices zu befolgen und unnötige Probleme im weiteren Entwicklungsprozess zu vermeiden. In dieser Lektion erfahren Sie, wie Sie mehrere APKs Ihrer App erstellen, die jeweils eine andere Teilmenge von OpenGL-Texturformaten unterstützen. Außerdem erhalten Sie einige Tools, die erforderlich sind, um die Verwaltung einer Codebasis mit mehreren APKs so einfach wie möglich zu gestalten.
Prüfen, ob Sie mehrere APKs benötigen
Wenn Sie versuchen, eine App zu erstellen, die auf allen verfügbaren Android-Geräten funktioniert, möchten Sie natürlich, dass Ihre App auf jedem einzelnen Gerät optimal dargestellt wird, auch wenn nicht alle dieselben GL-Texturen unterstützen. Zu Beginn mag es so aussehen, als wäre die Unterstützung mehrerer APKs die beste Lösung, aber das ist oft nicht der Fall. Im Abschnitt Verwenden eines einzelnen APK des Entwicklerhandbuchs für mehrere APKs finden Sie einige nützliche Informationen dazu, wie Sie dies mit einem einzelnen APK erreichen können, z. B. wie Sie unterstützte Texturformate zur Laufzeit erkennen. Je nach Ihrer Situation ist es möglicherweise einfacher, alle Formate mit Ihrer Anwendung zu bündeln und einfach nur das zur Laufzeit zu verwendende auszuwählen.
Wenn Sie es verwalten können, bietet es mehrere Vorteile, Ihre App auf ein einzelnes APK zu beschränken:
- Einfacheres Veröffentlichen und Testen
- Es muss nur eine Codebasis verwaltet werden
- Deine App kann sich an Änderungen der Gerätekonfiguration anpassen
- App-Wiederherstellung auf allen Geräten funktioniert einfach
- Sie müssen sich keine Gedanken über die Marktpräferenz, das Verhalten von Upgrades von einem APK auf das nächste oder darüber machen, welches APK zu welcher Geräteklasse gehört.
Im Rest dieser Lektion wird davon ausgegangen, dass Sie das Thema recherchiert, das Material in die verlinkten Ressourcen aufgenommen und entschieden haben, dass Sie mehrere APKs für Ihre App verwenden.
Anforderungen im Diagramm darstellen
Im Android-Entwicklerleitfaden finden Sie auf der Seite supports-gl-texture eine praktische Übersicht zu einigen häufig unterstützten Texturen. Diese Seite enthält auch einige Hinweise dazu, welche Smartphones (oder Smartphonefamilien) bestimmte Texturformate unterstützen. Generell empfiehlt es sich, eines Ihrer APKs ETC1 zu unterstützen, da dieses Texturformat von allen Android-Geräten unterstützt wird, die die OpenGL ES 2.0-Spezifikation unterstützen.
Da die meisten Android-Geräte mehr als ein Texturformat unterstützen, müssen Sie eine Reihenfolge festlegen. Erstellen Sie ein Diagramm mit allen Formaten, die von Ihrer Anwendung unterstützt werden. Die Zelle ganz links hat die niedrigste Priorität (es ist wahrscheinlich ETC1, ein wirklich solider Standard in Bezug auf Leistung und Kompatibilität). Färben Sie dann das Diagramm so ein, dass jede Zelle ein APK darstellt.
| ETC1 | ATI | PowerVR |
Durch das Ausmalen im Diagramm wird dieser Leitfaden nicht nur weniger einfarbig, sondern auch die teaminterne Kommunikation erleichtert. Sie können nun jedes APK einfach als „blau“, „grün“ oder „rot“ statt als „dasjenige, das ETC1-Texturformate unterstützt“ usw. bezeichnen.
Alle gängigen Codes und Ressourcen in einem Bibliotheksprojekt platzieren
Unabhängig davon, ob Sie eine vorhandene Android-App modifizieren oder eine neue App erstellen möchten, ist dies das Erste, was Sie mit der Codebasis tun sollten, und ist bei Weitem der wichtigste. Alles, was in das Bibliotheksprojekt einfließt, muss nur einmal aktualisiert werden (z. B. sprachspezifische Strings, Farbthemen, behobene Fehler im gemeinsam genutzten Code). Dadurch wird die Entwicklungszeit verkürzt und die Wahrscheinlichkeit von Fehlern reduziert, die sich einfach vermeiden lassen.
Hinweis:Die Implementierungsdetails zum Erstellen und Einbinden von Bibliotheksprojekten werden in dieser Lektion nicht behandelt. Mit Android-Bibliothek erstellen können Sie sich jedoch schnell einarbeiten.
Wenn Sie eine bestehende App konvertieren, um die Unterstützung für mehrere APKs zu verwenden, durchsuchen Sie Ihre Codebasis nach jeder lokalisierten Stringdatei, einer Liste von Werten, Designs, Menüsymbolen und einem Layout, die sich in den APKs nicht ändern sollen, und fügen Sie alles im Bibliotheksprojekt ein. Code, der sich kaum ändert, sollte auch in das Bibliotheksprojekt Wahrscheinlich werden Sie diese Klassen um eine oder zwei Methoden von APK zu APK erweitern.
Wenn Sie die App hingegen von Grund auf neu erstellen, versuchen Sie so viel wie möglich, zuerst Code in das Bibliotheksprojekt zu schreiben, und verschieben Sie diese dann nur bei Bedarf in ein einzelnes APK. Das ist auf lange Sicht viel einfacher zu verwalten, als den Blob zu einem und dann einem anderen hinzuzufügen und dann Monate später herauszufinden, ob dieses Blob in den Bibliotheksabschnitt verschoben werden kann, ohne irgendetwas zu beeinträchtigen.
Neue APK-Projekte erstellen
Für jedes APK, das du veröffentlichen möchtest, sollte es ein separates Android-Projekt geben. Zur einfacheren Organisation solltest du das Bibliotheksprojekt und alle zugehörigen APK-Projekte unter demselben übergeordneten Ordner ablegen. Denken Sie auch daran, dass jedes APK denselben Paketnamen haben muss, auch wenn nicht unbedingt der Paketname an die Bibliothek weitergegeben werden muss. Wenn Sie nach dem oben beschriebenen Schema drei APKs haben, könnte Ihr Stammverzeichnis so aussehen:
alexlucas:~/code/multi-apks-root$ ls foo-blue foo-green foo-lib foo-red
Fügen Sie nach dem Erstellen der Projekte das Bibliotheksprojekt als Referenz zu jedem APK-Projekt hinzu. Definieren Sie nach Möglichkeit Ihre Startaktivität im Bibliotheksprojekt und erweitern Sie diese Aktivität in Ihrem APK-Projekt. Wenn Sie eine Startaktivität im Bibliotheksprojekt definiert haben, können Sie die gesamte Initialisierung Ihrer App an einem Ort speichern. So muss nicht jedes einzelne APK „universelle“ Aufgaben wie das Initialisieren von Analytics, das Ausführen von Lizenzüberprüfungen und andere Initialisierungsverfahren, die sich von APK zu APK kaum ändern, neu implementieren.
Manifeste anpassen
Wenn ein Nutzer eine App herunterlädt, die mehrere APKs über Google Play verwendet, wird anhand einiger einfacher Regeln das richtige APK ausgewählt:
- Das Manifest muss zeigen, dass das jeweilige APK berechtigt ist
- Die höchste Versionsnummer der zulässigen APKs gewinnt
- Wenn irgendein der in Ihrem APK aufgeführten Texturformate vom auf dem Markt erhältlichen Gerät unterstützt wird, gilt dieses Gerät als zulässig
Im Hinblick auf GL-Texturen ist diese letzte Regel wichtig. Das bedeutet, dass Sie z. B. sehr vorsichtig sein sollten, wenn Sie verschiedene GL-Formate in derselben Anwendung verwenden. Wenn Sie PowerVR 99% der Zeit verwendet haben, aber ETC1 für beispielsweise Ihren Ladebildschirm nutzen... Dann würde Ihr Manifest unbedingt angeben, dass beide Formate unterstützt werden. Ein Gerät, das nur ETC1 unterstützt, gilt als kompatibel, Ihre App wird heruntergeladen und der Nutzer sieht einige spannende Absturzmeldungen. Wenn Sie mehrere APKs speziell für die Ausrichtung auf verschiedene Geräte basierend auf der GL-Texturunterstützung verwenden, wird ein Texturformat pro APK verwendet.
Dadurch unterscheidet sich die Texturunterstützung etwas von den beiden anderen APK-Abmessungen, API-Ebene und Bildschirmgröße. Jedes Gerät hat nur ein API-Level und eine Bildschirmgröße. Es hängt vom APK ab, ob er mehrere dieser Funktionen unterstützt. Bei Texturen unterstützt das APK in der Regel eine Textur, das Gerät wiederum viele. Es gibt oft Überschneidungen in Bezug darauf, dass ein Gerät viele APKs unterstützt, aber die Lösung ist dieselbe: die Versionscodes.
Nehmen wir zum Beispiel ein paar Geräte und prüfen Sie, wie viele der zuvor definierten APKs zu jedem Gerät passen.
| Smartphone | Nexus S | Logo: Evo |
| ETC1 | ETC1 | ETC1 |
| PowerVR | ATI TC |
Unter der Annahme, dass sowohl PowerVR- als auch ATI-Formate gegenüber ETC1 bevorzugt werden, sofern verfügbar, und nicht gemäß der Regel mit der höchsten Versionsnummer gewinnt, wenn wir das versionCode-Attribut in jedem APK so einstellen, dass Rot ≥ grün ≥ blau ist, werden auf Geräten, die sie unterstützen, immer sowohl Rot als auch Grün gegenüber Blau ausgewählt, und falls ein Gerät kommt, das sowohl Rot als auch Grün unterstützt, wird Rot ausgewählt.
Damit alle Ihre APKs auf separaten „Tracks“ gespeichert werden, ist es wichtig, ein gutes Versionscodeschema zu haben. Die empfohlene Version finden Sie im Bereich „Versionscodes“ unseres Entwicklerhandbuchs. Da sich der Beispielsatz der APKs nur mit einer von drei möglichen Dimensionen befasst, reicht es aus, jedes APK um 1.000 zu trennen und von dort weiter zu erhöhen. Das könnte so aussehen:
Blau: 1001, 1002, 1003, 1004...
Grün: 2001, 2002, 2003, 2004...
Rot:3001, 3002, 3003, 3004...
Wenn alles zusammengenommen würde, würde Ihr Android-Manifest wahrscheinlich in etwa so aussehen:
Blau:
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
android:versionCode="1001" android:versionName="1.0" package="com.example.foo">
<supports-gl-texture android:name="GL_OES_compressed_ETC1_RGB8_texture" />
...
Grün:
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
android:versionCode="2001" android:versionName="1.0" package="com.example.foo">
<supports-gl-texture android:name="GL_AMD_compressed_ATC_texture" />
...
Rot:
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
android:versionCode="3001" android:versionName="1.0" package="com.example.foo">
<supports-gl-texture android:name="GL_IMG_texture_compression_pvrtc" />
...
Checkliste vor dem Start prüfen
Überprüfen Sie vor dem Hochladen bei Google Play die folgenden Punkte. Diese sind für mehrere APKs relevant und stellen keineswegs eine vollständige Checkliste für alle Apps dar, die bei Google Play hochgeladen werden.
- Alle APKs müssen denselben Paketnamen haben
- Alle APKs müssen mit demselben Zertifikat signiert sein.
- Überprüfe deine Manifest-Filter auf widersprüchliche Informationen. Ein APK, das Cupcake nur auf XLARGE-Bildschirmen unterstützt, kann niemand sehen.
- Das Manifest jedes APK muss für mindestens eine unterstützte Bildschirm-, OpenGL-Textur- oder Plattformversion eindeutig sein.
- Testen Sie jedes APK auf mindestens einem Gerät. Abgesehen davon haben Sie einen der am besten anpassbaren Geräteemulatoren der Branche auf Ihrem Entwicklungscomputer. Mach mal was!
Es lohnt sich auch, das kompilierte APK vor der Veröffentlichung zu überprüfen, um sicherzustellen, dass Ihre App bei Google Play keine Überraschungen verbirgt. Mit dem Tool „aapt“ geht dies ziemlich einfach. Aapt (das Android Asset Packaging Tool) ist Teil des Build-Prozesses zum Erstellen und Packen Ihrer Android-Anwendungen und außerdem ein sehr praktisches Tool für die Prüfung.
>aapt dump badging package: name='com.example.hello' versionCode='1' versionName='1.0' sdkVersion:'11' uses-permission:'android.permission.SEND_SMS' application-label:'Hello' application-icon-120:'res/drawable-ldpi/icon.png' application-icon-160:'res/drawable-mdpi/icon.png' application-icon-240:'res/drawable-hdpi/icon.png' application: label='Hello' icon='res/drawable-mdpi/icon.png' launchable-activity: name='com.example.hello.HelloActivity' label='Hello' icon='' uses-feature:'android.hardware.telephony' uses-feature:'android.hardware.touchscreen' main supports-screens: 'xlarge' supports-any-density: 'true' locales: '--_--' densities: '120' '160' '240'
Achten Sie bei der Überprüfung der aapt-Ausgabe darauf, dass Sie keine widersprüchlichen Werte für „supports-screens“ und „compatible-screens“ sowie keine unbeabsichtigten „uses-feature“-Werte haben, die als Ergebnis von im Manifest festgelegten Berechtigungen hinzugefügt wurden. Im Beispiel oben ist das APK für die meisten, wenn nicht sogar für alle Geräte, nicht sichtbar.
Warum? Durch Hinzufügen der erforderlichen Berechtigung „SEND_SMS“ wurde die Funktionsanforderung von „android.hardware.telephony“ implizit hinzugefügt. Da es sich bei den meisten (wenn nicht allen) großen Geräten um Tablets ohne Telefonie-Hardware handelt, filtert Google Play dieses APK in diesen Fällen heraus, bis zukünftige Geräte verfügbar sind, die beide groß genug sind, um als XLarge-Bildschirm zu melden und über Telefoniehardware verfügen.
Zum Glück lässt sich das leicht beheben, indem du deinem Manifest Folgendes hinzufügst:
<uses-feature android:name="android.hardware.telephony" android:required="false" />
Die android.hardware.touchscreen-Anforderung wird ebenfalls implizit hinzugefügt. Wenn Sie möchten, dass Ihr APK auf Fernsehern sichtbar ist, die keine Touchscreen-Geräte sind, fügen Sie Ihrem Manifest Folgendes hinzu:
<uses-feature android:name="android.hardware.touchscreen" android:required="false" />
Wenn du die Checkliste vor dem Start abgearbeitet hast, lade deine APKs bei Google Play hoch. Es kann etwas dauern, bis die App beim Stöbern bei Google Play angezeigt wird. Führen Sie in diesem Fall eine letzte Überprüfung durch. Laden Sie die App auf alle Testgeräte herunter, um sicherzustellen, dass die APKs auf die gewünschten Geräte ausgerichtet sind. Herzlichen Glückwunsch, Sie sind fertig!