Mehrere APKs für verschiedene API-Ebenen erstellen

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.

Wenn Sie Ihre Android-Anwendung so entwickeln, dass Sie mehrere APKs bei Google Play nutzen können, sollten Sie von Anfang an einige Best Practices beachten, um spätere Probleme zu vermeiden. In dieser Lektion erfahren Sie, wie Sie mehrere APKs Ihrer App erstellen, die jeweils einen etwas anderen Bereich von API-Ebenen abdecken. Außerdem erhalten Sie einige Tools, die die Verwaltung einer Codebasis mit mehreren APKs so einfach wie möglich machen.

Prüfen, ob mehrere APKs erforderlich sind

Wenn Sie eine Anwendung entwickeln, die auf mehreren Generationen der Android-Plattform funktioniert, möchten Sie natürlich, dass Ihre Anwendung die neuen Funktionen auf neuen Geräten nutzt, ohne die Abwärtskompatibilität zu beeinträchtigen. Auf den ersten Blick mag es so aussehen, als wäre der Support für mehrere APKs die beste Lösung, aber das ist oft nicht der Fall. Im Abschnitt Stattdessen ein einzelnes APK verwenden des Entwicklerhandbuchs für mehrere APKs finden Sie einige nützliche Informationen dazu, wie Sie dies mit einem einzelnen APK erreichen, einschließlich der Verwendung 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 Ihre Anwendung auf ein einzelnes APK beschränken können, hat das mehrere Vorteile:

• Einfachere Veröffentlichung und Tests
• Es muss nur eine Codebasis verwaltet werden
• Ihre Anwendung kann sich an Änderungen der Gerätekonfiguration anpassen
• Geräteübergreifende App-Wiederherstellung funktioniert einfach
• Sie müssen sich keine Gedanken über Marktpräferenzen, das Verhalten bei 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 sich mit dem Thema befasst, sich das Material in den verlinkten Ressourcen sorgfältig angesehen und festgestellt haben, dass mehrere APKs der richtige Weg für Ihre Anwendung sind.

Anforderungen skizzieren

Erstellen Sie zuerst ein einfaches Diagramm, um schnell zu ermitteln, wie viele APKs Sie benötigen und welchen API-Bereich jedes APK abdeckt. Auf der Seite Plattformversionen der Android-Entwicklerwebsite finden Sie Daten zur relativen Anzahl der aktiven Geräte, auf denen eine bestimmte Version der Android-Plattform ausgeführt wird. Außerdem ist es zwar auf den ersten Blick einfach, aber es wird schnell schwierig, den Überblick darüber zu behalten, auf welche API-Ebenen jedes APK ausgerichtet ist, insbesondere wenn es Überschneidungen gibt (was oft der Fall ist). Glücklicherweise ist es ganz einfach, Ihre Anforderungen schnell und einfach zu skizzieren und für später als Referenz zu speichern.

Um ein Diagramm mit mehreren APKs zu erstellen, beginnen Sie mit einer Zeile von Zellen, die die verschiedenen API-Ebenen der Android-Plattform darstellen. Fügen Sie am Ende eine zusätzliche Zelle für zukünftige Android-Versionen hinzu.

Färben Sie das Diagramm nun so ein, dass jede Farbe ein APK darstellt. Hier ein Beispiel dafür, wie Sie jedes APK auf einen bestimmten Bereich von API-Ebenen anwenden können.

Nachdem Sie dieses Diagramm erstellt haben, senden Sie es an Ihr Team. Die Teamkommunikation zu Ihrem Projekt wurde jetzt noch einfacher.Anstatt zu fragen: „Wie sieht es mit der APK für die API-Ebenen 3 bis 6 aus, ähm, die für Android 1.x?“ Wie läuft es?“ Sie können einfach sagen: „Wie weit ist das Blue-APK?“

Alle gängigen Code- und Ressourcen in ein Bibliotheksprojekt einfügen

Ganz gleich, ob Sie eine vorhandene Android-Anwendung ändern oder eine neue erstellen, ist dies die erste und mit Abstand wichtigste Änderung, die Sie an der Codebasis vornehmen sollten. 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 Einbinden von Bibliotheksprojekten fallen nicht in den Rahmen dieser Lektion. Weitere Informationen finden Sie unter Android-Bibliothek erstellen.

Wenn Sie eine vorhandene Anwendung so konvertieren, dass sie mehrere APKs unterstützt, durchsuchen Sie Ihre Codebasis nach allen lokalisierten Stringdateien, Listen von Werten, Themenfarben, Menüsymbolen und Layouts, die sich nicht in den APKs ändern, und fügen Sie sie dem Bibliotheksprojekt hinzu. Code, der sich nicht wesentlich ändern wird, sollte ebenfalls in das Bibliotheksprojekt aufgenommen werden. Sie werden diese Klassen wahrscheinlich erweitern, um eine oder zwei Methoden von 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. Das ist auf lange Sicht viel einfacher, als ihn erst einem, dann einem anderen und dann noch einem anderen hinzuzufügen und dann Monate später herauszufinden, ob dieser Blob in den Bibliotheksabschnitt verschoben werden kann, ohne etwas zu vermasseln.

Neue APK-Projekte erstellen

Für jedes APK, das Sie veröffentlichen möchten, sollte ein separates Android-Projekt vorhanden sein. Für eine einfache Organisation sollten Sie das Bibliotheksprojekt und alle zugehörigen APK-Projekte im selben übergeordneten Ordner ablegen. Denken Sie auch daran, dass jedes APK denselben Paketnamen haben muss, der aber nicht unbedingt mit dem der Bibliothek übereinstimmen muss. Wenn Sie drei APKs gemäß dem oben beschriebenen Schema 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 jedem APK-Projekt als Referenz hinzu. Definieren Sie nach Möglichkeit die Startaktivität im Bibliotheksprojekt und erweitern Sie diese Aktivität in Ihrem APK-Projekt. Wenn Sie im Bibliotheksprojekt eine Startaktivität definieren, können Sie die gesamte Anwendungsinitialisierung an einem Ort zusammenfassen. So müssen für jedes einzelne APK nicht wieder „universelle“ Aufgaben wie die Initialisierung von Analytics, die Ausführung von Lizenzprüfungen und andere Initialisierungsverfahren implementiert werden, die sich von APK zu APK nicht wesentlich ändern.

Manifeste anpassen

Wenn ein Nutzer eine Anwendung herunterlädt, die mehrere APKs verwendet, wird die richtige APK anhand von zwei einfachen Regeln ausgewählt:

• Im Manifest muss angegeben sein, dass das betreffende APK berechtigt ist.
• Von den infrage kommenden APKs hat das APK mit der höchsten Versionsnummer Vorrang.

Nehmen wir als Beispiel die oben beschriebenen mehrere APKs und gehen davon aus, dass wir für keines der APKs eine maximale API-Ebene festgelegt haben. Einzeln betrachtet würde der mögliche Bereich jedes APK so aussehen:

Da ein APK mit einer höheren minSdkVersion auch einen höheren Versionscode haben muss, wissen wir, dass rot ≥ grün ≥ blau ist. Daher können wir das Diagramm minimieren, sodass es so aussieht:

Angenommen, das rote APK hat eine Anforderung, die die anderen beiden nicht haben. Auf der Seite Filter bei Google Play des Android-Entwicklerleitfadens finden Sie eine vollständige Liste möglicher Ursachen. Angenommen, für die Farbe Rot ist eine Frontkamera erforderlich. Der rote APK dient dazu, die Frontkamera mit neuen Funktionen zu kombinieren, die in API 11 hinzugefügt wurden. Aber wie sich herausstellte, haben nicht alle Geräte, die API 11 unterstützen, überhaupt eine Frontkamera. Das ist schrecklich!

Wenn ein Nutzer Google Play jedoch von einem solchen Gerät aus besucht, sieht Google Play im Manifest, dass Red die Frontkamera als Anforderung angibt, und ignoriert sie stillschweigend, da festgestellt wurde, dass Red und dieses Gerät nicht zusammenpassen. Es wird dann festgestellt, dass „Grün“ nicht nur mit Geräten mit API 11 kompatibel ist (da keine maxSdkVersion definiert wurde), sondern auch nicht darauf achtet, ob eine Frontkamera vorhanden ist. Die App kann vom Nutzer weiterhin bei Google Play heruntergeladen werden, da es trotz des Frontkamera-Fehlers noch eine APK gab, die dieses bestimmte API-Level unterstützte.

Damit alle Ihre APKs in separaten „Tracks“ bleiben, ist ein gutes Versionscode-Schema wichtig. Die empfohlene Version findest du im Abschnitt Versionscodes unseres Entwicklerhandbuchs. Da es sich bei den Beispiel-APKs nur um eine von drei möglichen Dimensionen handelt, reicht es aus, die einzelnen APKs um 1.000 zu trennen, die ersten Ziffern auf die minSdkVersion für das jeweilige APK festzulegen und von dort aus zu inkrementieren. Das könnte so aussehen:

Blau: 03001, 03002, 03003, 03004…
Grün: 07001, 07002, 07003, 07004…
Rot:11001, 11002, 11003, 11004...

Zusammengenommen sehen Ihre Android-Manifeste in etwa so aus:

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

Prüfen Sie vor dem Hochladen bei Google Play die folgenden Punkte. Denken Sie daran, dass diese Punkte speziell für mehrere APKs relevant sind und keine vollständige Checkliste für alle Anwendungen darstellen, 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 einen höheren Versionscode haben.
• Prüfen Sie Ihre Manifestfilter auf widersprüchliche Informationen. Ein APK, das nur Cupcake auf XLARGE-Displays unterstützt, wird von niemandem gesehen.
• Das Manifest jedes APKs muss für mindestens einen unterstützten Bildschirm, eine unterstützte OpenGL-Textur oder eine unterstützte Plattformversion eindeutig sein.
• Testen Sie jedes APK auf mindestens einem Gerät. Andernfalls haben Sie auf Ihrem Entwicklungscomputer einen der am besten anpassbaren Geräteemulatoren der Branche. Viel Spaß!

Es empfiehlt sich auch, das kompilierte APK vor der Veröffentlichung zu prüfen, um sicherzugehen, dass keine Überraschungen auftreten, die Ihre App bei Google Play verbergen könnten. Mit dem Tool „aapt“ ist das ganz einfach. 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: 'small' 'normal' 'large' 'xlarge'
supports-any-density: 'true'
locales: '--_--'
densities: '120' '160' '240'

Prüfen Sie bei der aapt-Ausgabe, ob es in Konflikt stehende Werte für „supports-screens“ und „compatible-screens“ gibt und ob nicht beabsichtigte „uses-feature“-Werte vorhanden sind, die aufgrund von Berechtigungen hinzugefügt wurden, die Sie im Manifest festgelegt haben. Im Beispiel oben ist die APK für nicht sehr viele Geräte sichtbar.

Was steckt dahinter? Durch das Hinzufügen der erforderlichen Berechtigung „SEND_SMS“ wurde die Funktionsanforderung „android.hardware.telephony“ implizit hinzugefügt. Da API 11 Honeycomb ist (die speziell für Tablets optimierte Version von Android) und keine Honeycomb-Geräte Telefoniehardware haben, wird dieses APK von Google Play in allen Fällen herausgefiltert, bis zukünftige Geräte mit einem höheren API-Level UND Telefoniehardware auf den Markt kommen.

Glücklicherweise lässt sich das Problem ganz einfach beheben, indem Sie Ihrem Manifest Folgendes hinzufügen:

<uses-feature android:name="android.hardware.telephony" android:required="false" />

Die Anforderung für android.hardware.touchscreen wird ebenfalls implizit hinzugefügt. Wenn Ihr APK auf Fernsehern ohne Touchscreen angezeigt werden soll, fügen Sie Ihrem Manifest Folgendes hinzu:

<uses-feature android:name="android.hardware.touchscreen" android:required="false" />

Nachdem Sie die Checkliste vor der Veröffentlichung durchgegangen sind, 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 Anwendung auf alle Testgeräte herunter, die Sie haben, um sicherzustellen, dass die APKs auf die gewünschten Geräte ausgerichtet sind. Herzlichen Glückwunsch, Sie sind fertig.