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 wird beschrieben, wie du mehrere APKs deiner App erstellst, die jeweils einen leicht unterschiedlichen Bereich von API-Levels abdecken. Außerdem erhältst du einige Tools, die die Verwaltung einer Codebasis für mehrere APKs so einfach wie möglich gestalten.
Prüfen, ob Sie mehrere APKs benötigen
Wenn Sie versuchen, eine App zu erstellen, die über mehrere Generationen der Android-Plattform hinweg funktioniert, möchten Sie natürlich, dass Ihre App die neuen Funktionen auf neuen Geräten nutzt, ohne die Abwärtskompatibilität zu beeinträchtigen. Zu Beginn scheint es so, als ob die Unterstützung mehrerer APKs die beste Lösung ist, aber das ist oft nicht der Fall. Im Abschnitt Verwenden eines einzelnen APKs des Entwicklerhandbuchs für mehrere APKs finden Sie einige nützliche Informationen dazu, wie Sie dies mit einem einzelnen APK erreichen können, einschließlich unserer Supportbibliothek. Außerdem erfahren Sie, wie Sie Code schreiben, der nur auf bestimmten API-Ebenen in einem einzelnen APK ausgeführt wird, ohne auf rechenintensive Techniken wie die Reflexion aus diesem Artikel zurückzugreifen.
Wenn Sie es verwalten können, hat die Beschränkung Ihrer App auf ein einzelnes APK mehrere Vorteile:
- 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 welchen API-Bereich jedes APK abdeckt. Als Referenz enthält die Seite Plattformversionen der Website für Android-Entwickler Daten zur relativen Anzahl aktiver Geräte, auf denen eine bestimmte Version der Android-Plattform ausgeführt wird. Auch wenn es auf den ersten Blick einfach klingt, wird es ziemlich schnell schwierig, den Überblick darüber zu behalten, auf welche API-Levels jedes APK abzielen soll, insbesondere wenn es Überschneidungen gibt (oft). Glücklicherweise ist es einfach, Ihre Anforderungen schnell und einfach zu skizzieren und für später leicht zur Hand zu haben.
Wenn du dein Diagramm für mehrere APKs erstellen möchtest, beginne mit einer Zeile von Zellen, die die verschiedenen API-Ebenen der Android-Plattform darstellen. Am Ende wird eine zusätzliche Zelle für zukünftige Android-Versionen geworfen.
| 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | + |
Jetzt müssen Sie nur noch eine Farbe im Diagramm festlegen, sodass jede Farbe ein APK repräsentiert. Hier ist ein Beispiel dafür, wie du jedes APK auf einen bestimmten Bereich von API-Levels anwenden kannst.
| 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | + |
Nachdem Sie dieses Diagramm erstellt haben, verteilen Sie es an Ihr Team. Die Teamkommunikation bei Ihrem Projekt ist ab sofort einfacher geworden, da Sie nicht mehr fragen: "Wie ist das APK für API-Level 3 bis 6, äh, das Android 1.x-1. Wie läuft es damit?“ Sagen Sie einfach: „Wie funktioniert das blaue APK?“
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 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 gewinnt
Nehmen wir beispielsweise die zuvor beschriebenen APKs und nehmen wir an, dass für keines der APKs ein maximales API-Level festgelegt ist. Einzeln betrachtet sähe der mögliche Bereich der einzelnen APKs so aus:
| 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | + |
| 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | + |
| 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | + |
Da ein APK mit einer höheren minSdkVersion auch einen höheren Versionscode haben muss, wissen wir, dass in Bezug auf die versionCode-Werte Rot ≥ grün ≥ blau ist. Daher können wir das Diagramm praktisch so minimieren:
| 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | + |
Gehen wir nun weiter davon aus, dass das rote APK bestimmte Anforderungen hat, die die anderen beiden nicht erfüllen. Die Seite Filter bei Google Play im Android-Entwicklerhandbuch enthält eine vollständige Liste der möglichen Schuldige. Nehmen wir beispielsweise an, dass für Rot eine Frontkamera erforderlich ist. Der Sinn des roten APK besteht darin, die Frontkamera mit tollen neuen Funktionen zu kombinieren, die in API 11 hinzugefügt wurden. Es hat sich jedoch herausgestellt, dass nicht alle Geräte, die API 11 unterstützen, überhaupt Frontkameras haben. Das Grauen!
Glücklicherweise sieht sich Google Play das Manifest an, wenn ein Nutzer Google Play über ein solches Gerät surft, sieht, dass Red die Frontkamera als Anforderung auflistet, und ignoriert sie leise, da sie festgestellt hat, dass Rot und dieses Gerät keine Übereinstimmung im digitalen Himmel sind. Es sieht dann, dass Green nicht nur aufwärtskompatibel mit Geräten mit API 11 ist (da keine maxSdkVersion definiert wurde), sondern es spielt auch keine Rolle, ob eine Frontkamera vorhanden ist oder nicht. Die App kann weiterhin vom Nutzer bei Google Play heruntergeladen werden, denn trotz des ganzen Fehlers der Frontkamera gab es ein APK, das dieses spezielle 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. Da die Beispiel-APKs nur eine von drei möglichen Dimensionen behandeln, wäre es ausreichend, jedes APK durch 1.000 zu trennen, die ersten Ziffern auf die minSdkVersion für das jeweilige APK zu setzen und von dort zu erhöhen. Das könnte so aussehen:
Blau: 03001, 03002, 03003, 03004...
Grün: 07001, 07002, 07003, 07004...
Rot:11001, 11002, 11003, 11004...
Wenn alles zusammengenommen wird, würde Ihr Android-Manifest wahrscheinlich wie folgt aussehen:
Blau:
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
android:versionCode="03001" android:versionName="1.0" package="com.example.foo">
<uses-sdk android:minSdkVersion="3" />
...
Grün:
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
android:versionCode="07001" android:versionName="1.0" package="com.example.foo">
<uses-sdk android:minSdkVersion="7" />
...
Rot:
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
android:versionCode="11001" android:versionName="1.0" package="com.example.foo">
<uses-sdk android:minSdkVersion="11" />
...
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
- Überprüfen Sie Ihre Manifest-Filter auf widersprüchliche Informationen. Ein APK, das Cupcake nur auf XLARGE-Bildschirmen unterstützt, kann niemand sehen.
- Das Manifest jedes APKs muss für mindestens eine unterstützte Bildschirm-, OpenGL-Textur- oder Plattformversion eindeutig sein.
- Testen Sie jedes APK auf mindestens einem Gerät. Davon abgesehen 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: 'small' 'normal' 'large' '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 sehr viele 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 API 11 um Honeycomb (die speziell für Tablets optimierte Android-Version) handelt und keine Honeycomb-Geräte Telefoniehardware enthalten, wird dieses APK bei Google Play immer herausgefiltert, bis zukünftige Geräte auf einem höheren API-Level erscheinen 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!