Wenn Sie Ihre App bei Google Play veröffentlichen, sollten Sie eine Android App Bundle: In diesem Fall wird Google Play automatisch optimierte APKs für die Gerätekonfiguration der einzelnen Nutzer generiert und bereitgestellt, sodass sie nur den Code und die Ressourcen, die sie zum Ausführen Ihrer App benötigen. Das Veröffentlichen mehrerer APKs ist nützlich, wenn Sie nicht bei Google Play veröffentlichen, aber Sie müssen jedes APK selbst erstellen, signieren und verwalten.
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 bewährte Vorgehensweisen anzuwenden und unnötige Kopfschmerzen zu vermeiden. in den Entwicklungsprozess einfließen. In dieser Lektion erfährst du, wie du mehrere APKs deiner App, die jeweils eine andere Klasse von Bildschirmgrößen abdeckt. Außerdem lernen Sie einige Tools kennen, mit denen die Pflege einer Codebasis mit mehreren APKs so einfach wie möglich wird.
Prüfen, ob mehrere APKs erforderlich sind
Wenn Sie versuchen, eine App zu entwickeln, die mit einer Vielzahl von Android-Versionen kompatibel ist Ihre Anwendung sollte auf jedem Gerät optimal dargestellt werden. Sie möchten den Platz großer Bildschirme nutzen, aber auch auf kleinen Geräten arbeiten, neue Android API-Funktionen oder visuelle Texturen auf modernen Geräten verwenden, aber ältere nicht vernachlässigen. Möglicherweise Es scheint so, als sei die Unterstützung mehrerer APK-Dateien die beste Lösung, aber das ist oft nicht Fall. Die Verwendung Der Abschnitt zu einzelnen APKs des Leitfadens für mehrere APKs enthält nützliche Informationen dazu, wie du All dies erreichen Sie mit einem einzigen APK, einschließlich der Nutzung unserer Supportbibliothek, und Links zu Ressourcen im gesamten Android-Entwicklerhandbuch.
Die Beschränkung der App auf ein einziges APK hat mehrere Vorteile, einschließlich:
- Einfachere Veröffentlichung und Tests
- Es muss nur eine Codebasis verwaltet werden
- Deine App kann sich an Änderungen der Gerätekonfiguration anpassen
- Die geräteübergreifende App-Wiederherstellung funktioniert einfach
- Sie müssen sich keine Gedanken über Marktpräferenzen, das Verhalten von „Upgrades“ von einem APK in den oder welches APK zu welcher Geräteklasse gehört
Im weiteren Verlauf dieser Lektion wird davon ausgegangen, dass Sie das Thema recherchiert und das und haben festgestellt, dass mehrere APKs der richtige Weg für Ihr .
Anforderungen grafisch darstellen
Erstellen Sie zunächst ein einfaches Diagramm, um schnell zu ermitteln, wie viele APKs Sie benötigen und welchen Bildschirm Sie benötigen. Größe(n), die jedes APK abdeckt. Zum Glück können Sie Ihre Anforderungen schnell, einfach und für später leicht nachschlagen. Angenommen, Sie möchten Ihre APKs in zwei Dimensionen aufteilen, und Bildschirmgröße. Erstellen Sie eine Tabelle mit einer Zeile und Spalte für jedes mögliche Wertepaar und jede Farbe. in einigen Blobs, wobei jede Farbe für ein APK steht.
| 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | + | |
| klein | |||||||||||
| normal | |||||||||||
| groß | |||||||||||
| xlarge |
Oben sehen Sie ein Beispiel mit vier APKs. Blau steht für alle kleinen/normalen Geräte, Grün für große und Rot für Geräte mit großen Bildschirmen, alle mit einem API-Bereich von 3 bis 10. Lila ist ein Sonderfall, da dies für alle Bildschirmgrößen gilt, aber nur für API 11 und höher. Noch wichtiger ist, dass Sie mit einem Blick auf dieses Diagramm sofort erkennen, welches APK für eine bestimmte Kombination aus API und Bildschirmgröße verwendet wird. Bis gibt es auch mondäne Codenamen für jeden, denn "Haben wir schon Rot auf dem ?" ist viel einfacher zu fragen, als "Haben wir das 3-to-10 xlarge APK mit dem Xoom getestet?" Drucken Sie dieses Diagramm aus und geben Sie es an alle Personen weiter, die an Ihrer Codebasis arbeiten. Das Leben ist jetzt noch einfacher.
Alle gängigen Codes und Ressourcen in einem Bibliotheksprojekt speichern
Ganz gleich, ob Sie eine vorhandene Android-Anwendung ändern oder eine neue erstellen, ist dies das Erste, was Sie mit der Codebasis tun sollten, und bei weitem das Wichtigste. Alles, was in das Bibliotheksprojekt aufgenommen wird, muss nur einmal aktualisiert werden (z. B. sprachlokalisierte Strings, Farbthemen, im gemeinsamen Code behobene Fehler). Das verkürzt die Entwicklungszeit und verringert die Wahrscheinlichkeit von Fehlern, die leicht hätten vermieden werden können.
Hinweis:Die Implementierungsdetails zum Erstellen und Bibliotheksprojekte zu integrieren, geht es in dieser Lektion nicht. findest du unter Android-Mediathek erstellen.
Wenn Sie eine vorhandene Anwendung so konvertieren, dass sie mehrere APKs unterstützt, durchsuchen Sie Ihre Codebasis nach jeder lokalisierten Stringdatei, Werteliste, Themenfarbe, Menüsymbol und Layout, die sich nicht in den APKs ändern, und fügen Sie sie dem Bibliotheksprojekt hinzu. Code, der sich kaum verändert, sollte auch im Bibliotheksprojekt. Sie werden diese Funktionen wahrscheinlich -Klassen hinzufügen, um eine oder zwei Methoden vom APK zu APK hinzuzufügen.
Wenn Sie die Anwendung hingegen von Grund auf neu erstellen, sollten Sie zuerst Code im Bibliotheksprojekt schreiben und ihn dann nur bei Bedarf in ein einzelnes APK verschieben. Langfristig ist dies viel einfacher zu verwalten, dann noch einmal, dann noch einmal und Monate später, um herauszufinden, ohne etwas zu verschrauben.
Neue APK-Projekte erstellen
Für jedes APK, das Sie veröffentlichen möchten, sollte es ein separates Android-Projekt geben. Einfach Organisation erstellen, legen Sie das Bibliotheksprojekt und alle zugehörigen APK-Projekte im selben übergeordneten Ordner ab. Denken Sie auch daran, dass jedes APK denselben Paketnamen haben muss, auch wenn dies nicht zwangsläufig den Paketnamen mit der Bibliothek teilen müssen. Wenn Sie 3 APKs nach dem Schema haben müssten, wie oben beschrieben, könnte Ihr Stammverzeichnis wie folgt 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 die Startaktivität im Bibliotheksprojekt und erweitern Sie diese Aktivität in Ihrem APK-Projekt. Wenn Sie eine Anfangsaktivität im Bibliotheksprojekt definiert haben, die Initialisierung deiner App an einem Ort, damit die einzelnen APK-Dateien „universelle“ wie z. B. die Initialisierung von Analytics, die Durchführung von Lizenzüberprüfungen Initialisierungsverfahren, die sich von APK zu APK kaum ändern.
Manifeste anpassen
Wenn ein Nutzer über Google Play eine App herunterlädt, die mehrere APKs verwendet, Das zu verwendende APK wird anhand von zwei einfachen Regeln ausgewählt:
- Das Manifest muss anzeigen, dass ein bestimmtes APK zulässig ist
- Von den zulässigen APKs erhält die höchste Versionsnummer den Zuschlag.
Nehmen wir als Beispiel die oben beschriebenen mehrere APKs und gehen davon aus, dass jedes APK so konfiguriert ist, dass alle Bildschirmgrößen unterstützt werden, die größer als die „Ziel“-Bildschirmgröße sind. Sehen wir uns das Beispieldiagramm von vorhin:
| 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | + | |
| klein | |||||||||||
| normal | |||||||||||
| groß | |||||||||||
| xlarge |
Da es in Ordnung ist, wenn sich die Abdeckung überschneidet, können wir den von den einzelnen APKs abgedeckten Bereich folgendermaßen beschreiben: Also:
- Blau deckt alle Bildschirme ab, minSDK 3.
- Grün steht für große Bildschirme und höher, minSDK 3.
- XLarge-Bildschirme (in der Regel Tablets) sind rot markiert, minSDK 9.
- Lila deckt alle Bildschirme ab, minSDK von 11.
Beachten Sie, dass es viele Überschneidungen zwischen diesen Regeln gibt. Beispiel: Bei XLarge-Geräten mit API 11 kann auch jedes der 4 angegebenen APKs ausgeführt werden. Mit der Regel „Die höchste Versionsnummer hat Vorrang“ können wir jedoch eine Präferenzreihenfolge festlegen:
Lila ≥ Rot ≥ Grün ≥ Blau
Warum alle Überschneidungen zulassen? Nehmen wir an, das lila APK muss eine Anforderung erfüllen, die anderen beiden nicht. Die Seite Filter bei Google Play des Android-Entwicklerhandbuchs enthält eine vollständige Liste der möglichen Fehler. Als Beispiel nehmen wir an, dass für Lila eine Frontkamera erforderlich ist. Der Sinn von Lila ist es sogar, Unterhaltsame Dinge mit der Frontkamera nutzen Es stellte sich jedoch heraus, dass nicht alle Geräte mit sogar Frontkameras! Das ist schrecklich!
Wenn ein Nutzer Google Play jedoch von einem solchen Gerät aus besucht, sieht Google Play im Manifest, dass Purple die Frontkamera als Anforderung angibt, und ignoriert sie stillschweigend, da festgestellt wurde, dass Purple und dieses Gerät nicht zusammenpassen. Es wird dann dass Rot nicht nur mit XXL-Geräten kompatibel ist, sondern dass es auch egal ist, Es gibt eine Frontkamera! Die App kann weiterhin vom Nutzer bei Google Play heruntergeladen werden. denn trotz des Fehlers bei der Frontkamera gab es ein APK, das genau diese API-Level.
Damit Sie alle APKs in separaten „Tracks“ verwalten können, ist es wichtig, einen guten Versionscode zu haben. . Die empfohlene Version findest du im Abschnitt Versionscodes unseres Entwicklerhandbuchs. Es ist lohnenswert, den gesamten Abschnitt zu lesen. Der grundlegende Kern gilt jedoch für diese Reihe von APKs verwenden wir zwei Ziffern für das minSDK, zwei für die minimale bzw. maximale Bildschirmgröße und 3 um die Build-Nummer darzustellen. Wenn das Gerät auf eine neue Android-Version aktualisiert wurde, (z. B. 10 bis 11), alle APKs, die jetzt aktiv und gegenüber dem derzeit installierten APK bevorzugt werden vom Gerät als „Upgrade“ angesehen wird. Das Schema für die Versionsnummer könnte für die Beispiel-APKs so aussehen:
Blau: 0304001, 0304002, 0304003...
Grün: 0334001, 0334002, 0334003
Rot: 0344001, 0344002, 0344003...
Lila: 1104001, 1104002, 1104003...
Zusammengenommen würden Ihre Android-Manifeste wahrscheinlich so aussehen wie die Folgendes:
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 „supports-screens“ oder dem Tag „compatible-screens“. Unterstützt Bildschirme werden im Allgemeinen bevorzugt und es ist ein wirklich schlechter die Idee, beides zu verwenden. Dies macht die Dinge unnötig kompliziert und erhöht die Wahrscheinlichkeit von Fehlern. Anstatt die Standardwerte zu verwenden (klein und normal sind standardmäßig immer wahr), legen die Manifeste den Wert für jede Bildschirmgröße explizit fest. Dadurch können Sie Kopfzerbrechen - zum Beispiel ein Manifest mit einem SDK von < 9 haben eine sehr große Größe automatisch auf „false“ gesetzt, da diese Größe noch nicht vorhanden war. Seien Sie also ausdrücklich!
Checkliste vor dem Start prüfen
Überprüfen Sie die folgenden Punkte, bevor Sie sie bei Google Play hochladen. Denken Sie daran, dass diese die für mehrere APKs relevant sind und keinesfalls eine vollständige Checkliste für alle Apps, die auf 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 ein höheren Versionscode.
- Für jede Bildschirmgröße, die von deinem APK unterstützt werden soll, musst du im Manifest „true“ festlegen. Für jede Bildschirmgröße nicht auf "false" setzen.
- Überprüfe deine Manifestfilter auf widersprüchliche Informationen (ein APK, das nur wird der Cupcake auf XLARGE-Bildschirmen nicht von niemandem gesehen werden.)
- Jedes APK-Manifest muss für mindestens einen unterstützten Bildschirm, eine OpenGL-Textur oder Plattformversion.
- Testen Sie jedes APK auf mindestens einem Gerät. Davon abgesehen haben Sie eine der anpassbare Geräteemulatoren im Unternehmen auf deinem Entwicklungscomputer. Verrückt!
Es lohnt sich auch, das kompilierte APK zu prüfen, bevor es auf den Markt gebracht wird, um sicherzustellen, dass keine eventuelle Überraschungen, die Ihre App bei Google Play verstecken könnten. Das geht ganz einfach über die „aapt“ . Aapt (Android Asset Packaging Tool) ist Teil des Build-Prozesses zum Erstellen und Verpacken Ihrer Android-Anwendungen und auch ein sehr praktisches Tool zum Prüfen derselben.
>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 Prüfung der aapt-Ausgabe darauf, dass Sie keine widersprüchlichen Werte für "unterstützt-Bildschirme" und "Kompatible Bildschirme" enthält und dass es keine unbeabsichtigten Werte die aufgrund von Berechtigungen hinzugefügt wurden, die du im Manifest festgelegt hast. Im obigen Beispiel hat das APK sind auf den meisten, wenn nicht sogar auf allen Geräten unsichtbar.
Was steckt dahinter? Durch das 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 sogar allen) großen Geräten um Tablets handelt, die keine Telefoniehardware enthalten, filtert Google Play dieses APK in diesen Fällen heraus, bis zukünftige Geräte verfügbar sind, die beide groß genug sind, um eine Meldung über eine große Bildschirmgröße zu erstellen und über Telefoniehardware zu verfügen.
Dieses Problem lässt sich leicht beheben, indem du Folgendes zu deinem Manifest hinzufügst:
<uses-feature android:name="android.hardware.telephony" android:required="false" />
Die android.hardware.touchscreen-Anforderung wird ebenfalls implizit hinzugefügt. Wenn du möchtest, dass dein APK auf Fernsehern ohne Touchscreen angezeigt wird, solltest du deinem Manifest Folgendes hinzufügen:
<uses-feature android:name="android.hardware.touchscreen" android:required="false" />
Nachdem Sie die Schritte der Checkliste vor der Veröffentlichung abgeschlossen haben, laden Sie Ihre APKs bei Google Play hoch. Es kann etwas dauern, bis die App bei der Suche in Google Play angezeigt wird. Wenn das der Fall ist, führen Sie noch eine letzte Prüfung durch. Laden Sie die App auf alle Testgeräte herunter, die Sie möglicherweise haben, um sicherzustellen, dass die APKs auf die gewünschten Geräte ausgerichtet sind. Herzlichen Glückwunsch, Sie haben es geschafft!