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 anzunehmen und unnötige Probleme im weiteren Verlauf des Entwicklungsprozesses zu vermeiden. In dieser Lektion erfährst du, wie du mehrere APKs deiner App erstellst, die jeweils eine andere Klasse von Bildschirmgrößen abdecken. 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, sollte Ihre App auf jedem einzelnen Gerät optimal dargestellt werden. Sie möchten die Vorteile der großen Bildschirme nutzen, aber trotzdem auf kleinen Bildschirmen arbeiten, um neue Android API-Funktionen oder visuelle Texturen auf modernen Geräten zu nutzen, aber nicht auf ältere Geräte verzichten. Zu Beginn mag es so aussehen, als wäre die Unterstützung mehrerer APK-Dateien die beste Lösung, aber das ist oft nicht der Fall. Der Abschnitt Stattdessen ein einzelnes APK verwenden im Leitfaden für mehrere APKs enthält einige nützliche Informationen dazu, wie du all dies mit einem einzigen APK erreichen kannst, einschließlich unserer Supportbibliothek, und Links zu Ressourcen im gesamten Android-Entwicklerleitfaden.
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
Erstellen Sie zuerst ein einfaches Diagramm, um schnell zu ermitteln, wie viele APKs Sie benötigen und welche Bildschirmgröße(n) jedes APK abdeckt. Zum Glück ist es ganz einfach, Ihre Anforderungen schnell und einfach zu skizzieren und für später zur Hand zu haben. Angenommen, Sie möchten Ihre APKs in zwei Dimensionen, API und Bildschirmgröße, aufteilen. Erstellen Sie eine Tabelle mit einer Zeile und Spalte für jedes mögliche Wertepaar und Farbe in einigen "Blobs", wobei jede Farbe ein APK darstellt.
| 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | + | |
| klein | |||||||||||
| normal | |||||||||||
| groß | |||||||||||
| xlarge |
Oben siehst du ein Beispiel mit vier APKs. Blau steht für alle Geräte mit kleinen/normalen Bildschirmen, Grün für Geräte mit großen Bildschirmen und Rot für Geräte mit großem Bildschirm, alle mit einem API-Bereich von 3 bis 10. Violett ist ein Sonderfall, da es für alle Bildschirmgrößen gilt, aber nur für API 11 und höher. Und was noch wichtiger ist: Mit einem Blick auf dieses Diagramm können Sie sofort erkennen, welches APK eine bestimmte Kombination aus API und Bildschirmgröße abdeckt. Zum Starten gibt es auch mondäne Codenamen für jedes Spiel. „Haben wir rot auf dem ? getestet?“ ist viel einfacher, Ihren Kunden zu fragen, als „Haben wir das 3-10-APK der Größe mit dem Xoom getestet?“. Drucken Sie dieses Diagramm aus und übergeben Sie es jeder Person, die an Ihrer Codebasis arbeitet. Das Leben ist jetzt viel einfacher.
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-purple 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 von zwei einfachen Regeln das richtige APK ausgewählt:
- Das Manifest muss zeigen, dass das jeweilige APK berechtigt ist
- Die höchste Versionsnummer der zulässigen APKs erhält den Zuschlag.
Nehmen wir beispielsweise die zuvor beschriebenen APKs und nehmen wir an, dass jedes APK alle Bildschirmgrößen unterstützt, die größer als seine "Zielbildschirmgröße" sind. Schauen wir uns das Beispieldiagramm von vorhin an:
| 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | + | |
| klein | |||||||||||
| normal | |||||||||||
| groß | |||||||||||
| xlarge |
Da eine Überschneidung der Abdeckung in Ordnung ist, können wir den von jedem APK abgedeckten Bereich so beschreiben:
- Blau deckt alle Bildschirme ab, minSDK 3.
- Grün deckt große Bildschirme und höher ab, minSDK 3.
- Rot deckt XLarge-Bildschirme (in der Regel Tablets) ab, minSDK 9.
- Lila deckt alle Bildschirme ab, minSDK-Version 11.
Beachten Sie, dass es viele Überschneidungen in diesen Regeln gibt. Auf einem XL-Gerät mit API 11 ist es beispielsweise möglich, eines der vier angegebenen APKs auszuführen. Mithilfe der Regel „Höchste Versionsnummer hat Vorrang“ können wir jedoch die folgende Präferenzreihenfolge festlegen:
Lila ≥ Rot ≥ Grün ≥ Blau
Warum sollte ich die Überschneidungen zulassen? Nehmen wir an, dass das lila APK bestimmte Anforderungen hat, die die anderen beiden nicht tun. Die Seite Filter bei Google Play im Android-Entwicklerleitfaden enthält eine vollständige Liste der möglichen Schuldige. Nehmen wir beispielsweise an, dass für die Farbe Lila eine Frontkamera benötigt wird. Purple hat den Zweck, unterhaltsame Dinge mit der Frontkamera zu gestalten. Es hat sich jedoch herausgestellt, dass nicht alle Geräte mit API 11 oder höher auch Frontkameras haben. Das Grauen!
Wenn ein Nutzer auf einem solchen Gerät bei Google Play surft, sieht sich Google Play das Manifest an, sieht, dass Lila die Frontkamera als Anforderung auflistet, und ignoriert sie leise, da Purple und dieses Gerät keine Übereinstimmung im digitalen Himmel darstellen. Dann ist Red nicht nur mit XL-Geräten kompatibel, sondern spielt auch keine Rolle, ob es eine Frontkamera gibt. Die App kann vom Nutzer bei Google Play heruntergeladen werden, denn trotz des ganzen Fehlers der Frontkamera gab es immer noch ein APK, das dieses bestimmte API-Level unterstützt.
Damit alle Ihre APKs auf separaten Tracks bleiben, ist es wichtig, ein gutes Versionscodeschema zu haben. Die empfohlene Version finden Sie im Bereich Versionscodes unseres Entwicklerhandbuchs. Es lohnt sich, den gesamten Abschnitt zu lesen, aber das Wichtigste ist, dass wir bei dieser Reihe von APKs zwei Ziffern für das minSDK, zwei für die minimale/maximale Bildschirmgröße und 3 für die Build-Nummer verwenden. Wenn das Gerät auf eine neue Android-Version aktualisiert wird (z. B. von 10 auf 11), werden alle APKs, die jetzt berechtigt und gegenüber der aktuell installierten Version bevorzugt werden, vom Gerät als „Upgrade“ angesehen. Wenn das Versionsnummernschema auf die Beispiel-APKs angewendet wird, könnte es so aussehen:
Blau: 0304001, 0304002, 0304003...
Grün: 0334001, 0334002, 0334003
Rot: 0344001, 0344002, 0344003...
Lila: 1104001, 1104002, 1104003...
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="0304001" android:versionName="1.0" package="com.example.foo">
<uses-sdk android:minSdkVersion="3" />
<supports-screens android:smallScreens="true"
android:normalScreens="true"
android:largeScreens="true"
android:xlargeScreens="true" />
...
Grün:
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
android:versionCode="0334001" android:versionName="1.0" package="com.example.foo">
<uses-sdk android:minSdkVersion="3" />
<supports-screens android:smallScreens="false"
android:normalScreens="false"
android:largeScreens="true"
android:xlargeScreens="true" />
...
Rot:
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
android:versionCode="0344001" android:versionName="1.0" package="com.example.foo">
<uses-sdk android:minSdkVersion="3" />
<supports-screens android:smallScreens="false"
android:normalScreens="false"
android:largeScreens="false"
android:xlargeScreens="true" />
...
Lila:
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
android:versionCode="1104001" android:versionName="1.0" package="com.example.foo">
<uses-sdk android:minSdkVersion="11" />
<supports-screens android:smallScreens="true"
android:normalScreens="true"
android:largeScreens="true"
android:xlargeScreens="true" />
...
Technisch gesehen funktionieren mehrere APKs entweder mit dem Tag "support-screens" oder mit dem Tag "compatible-screens". Die Unterstützung von Bildschirmen wird in der Regel bevorzugt und es ist im Allgemeinen eine schlechte Idee, beide zu verwenden. Dadurch wird die Sache unnötig kompliziert und Fehler treten auf. Beachten Sie auch, dass die Manifeste den Wert für jede Bildschirmgröße explizit festlegen, anstatt die Standardwerte zu nutzen (klein und normal sind standardmäßig immer „true“). Dies ersparen Ihnen Kopfzerbrechen. Beispielsweise wird in einem Manifest mit einem Ziel-SDK von < 9 automatisch „XL“ auf „false“ gesetzt, da diese Größe noch nicht vorhanden war. Seien Sie also bitte explizit!
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.
- Wenn sich die APKs in der Plattformversion überschneiden, muss das APK mit der höheren minSdkVersion einen höheren Versionscode haben.
- Jede Bildschirmgröße, die von deinem APK unterstützt werden soll, im Manifest auf „true“ gesetzt. Geben Sie für jede Bildschirmgröße, die vermieden werden soll, „false“ an.
- Ü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!