Preparing an Application for Release (Vorbereiten einer Anwendung auf die Veröffentlichung)

Nachdem eine Anwendung codiert und getestet wurde, ist es erforderlich, ein Paket zur Verteilung vorzubereiten. Die erste Aufgabe bei der Vorbereitung dieses Pakets liegt darin, die Anwendung für die Veröffentlichung zu erstellen, was hauptsächlich mit dem Festlegen einiger Anwendungsattribute verbunden ist.

Führen Sie die folgenden Schritte aus, um die App zur Veröffentlichung zu erstellen:

• Angeben des Anwendungssymbols – Für jede Xamarin.Android-Anwendung sollte ein Anwendungssymbol angegeben werden. Dies ist bei einigen Märkten wie Google Play erforderlich, obwohl keine technische Notwendigkeit besteht.

• Versionieren der Anwendung – In diesem Schritt werden die Versionsinformationen initialisiert oder aktualisiert. Dies ist wichtig für zukünftige Anwendungsupdates und um sicherzustellen, dass die Benutzer wissen, welche Version der Anwendung sie installiert haben.

• Verkleinern des APK – Die Größe des endgültigen APK kann mithilfe des Xamarin.Android-Linkers für den verwalteten Code sowie von ProGuard für den Java-Bytecode erheblich verringert werden.

• Schützen der Anwendung – Hindern Sie Benutzer oder Angreifer daran, die Anwendung zu debuggen, zu manipulieren oder zurückzuentwickeln, indem Sie Debugging deaktivieren, den verwalteten Code verbergen, Anti-Debug- und Anti-Manipulationsmaßnahmen hinzufügen und native Kompilierung verwenden.

• Festlegen von Paketeigenschaften – Mit Paketeigenschaften wird die Erstellung des Android-Anwendungspakets (APK) gesteuert. Dieser Schritt optimiert das APK, schützt dessen Objekte und modularisiert das Paket nach Bedarf. Zusätzlich können Sie ein Android-App Bundle für Ihre Benutzer bereitstellen, das für deren Geräte optimiert ist.

• Kompilieren – In diesem Schritt werden Code und Ressourcen kompiliert, um das Erstellen im Releasemodus sicherzustellen.

• Archivieren zur Veröffentlichung – In diesem Schritt wird die App erstellt und zum Signieren und Veröffentlichen in einem Archiv platziert.

Jeder dieser Schritte wird unten genauer beschrieben.

Angeben des Anwendungssymbols

Es wird dringend empfohlen, für jede Xamarin.Android-Anwendung ein Anwendungssymbol festzulegen. Einige Anwendungs-Marktplaces werden eine Veröffentlichung einer Android-Anwendung ohne ein solches Symbol nicht genehmigen. Die Eigenschaft Icon für das Application-Attribut (Anwendungsattribut) wird zur Festlegung eines Anwendungssymbols für ein Xamarin.Android-Projekt verwendet.

In diesen Beispielen bezieht sich @drawable/icon auf eine Symboldatei, die sich in Resources/drawable/icon.png befindet (Beachten Sie, dass die .PNG-Erweiterung nicht im Ressourcennamen enthalten ist). Das Attribut kann auch in der Datei Properties\AssemblyInfo.cs deklariert werden, wie im folgenden Beispiel gezeigt wird:

[assembly: Application(Icon = "@drawable/icon")]

In der Regel wird using Android.App am oberen Rand von AssemblyInfo.cs deklariert (der Namespace des Application-Attributs ist Android.App). Dennoch müssen Sie diese using-Anweisung hinzufügen, falls sie noch nicht vorhanden ist.

Versionieren der Anwendung

Die Versionsverwaltung ist wichtig für die Wartung und Verteilung von Android-Anwendungen. Ohne die Versionsverwaltung ist es schwierig zu bestimmen, ob oder wie eine Anwendung aktualisiert werden soll. Um Sie bei der Versionsverwaltung zu unterstützen, erkennt Android zwei verschiedene Arten von Informationen:

• Versionsnummer – Ein ganzzahliger Wert, der intern von Android und der Anwendung verwendet wird und die Version der Anwendung darstellt. In den meisten Anwendungen ist der Wert zunächst auf 1 festgelegt und wird mit jedem weiteren Build inkrementiert. Dieser Wert steht in keiner Verbindung oder Affinität zum Attribut des Versionsnamens (siehe unten). Anwendungen und Veröffentlichungsdienste sollten Benutzern diesen Wert nicht anzeigen. Dieser Wert wird in der Datei AndroidManifest.xml als android:versionCode gespeichert.

• Versionsname – Eine Zeichenfolge, deren einziger Zweck darin besteht, dem Benutzer Informationen zur Version der Anwendung bereitzustellen, die auf einem bestimmten Gerät installiert ist. Der Versionsname soll Benutzern angezeigt werden, z.B. in Google Play. Diese Zeichenfolge wird nicht intern von Android verwendet. Der Versionsname kann jeder beliebige Zeichenfolgenwert sein, anhand dessen ein Benutzer den Build bestimmen kann, der auf seinem Gerät installiert ist. Dieser Wert wird in der Datei AndroidManifest.xml als android:versionName gespeichert.

Verkleinern der APK

Xamarin.Android-APKs können durch eine Kombination des Linkers Xamarin.Android zum Entfernen von unnötigem verwalteten Code sowie des Tools ProGuard aus dem Android SDK zum Entfernen von nicht verwendetem Java-Bytecode verkleinert werden. Vom Erstellungsprozess wird zuerst der Linker Xamarin.Android zum Optimieren der App auf Ebene des verwalteten Codes (C#) und anschließend ProGuard (sofern aktiviert) zum Optimieren der APK auf Java-Bytecode-Ebene verwendet.

Konfigurieren des Linkers

Der Releasemodus deaktiviert die freigegebene Laufzeit und aktiviert die Verknüpfung, sodass die Anwendung nur die Teile von Xamarin.Android enthält, die zur Laufzeit erforderlich sind. Der Linker in Xamarin.Android bestimmt mithilfe von statischen Analysen, welche Assemblys, Typen und Typmember von einer Xamarin.Android-Anwendung verwendet oder referenziert werden. Anschließend verwirft der Linker alle ungenutzten Assemblys, Typen und Member, die nicht verwendet (oder referenziert) werden. Dies kann zu einer erheblichen Verringerung der Paketgröße führen. Betrachten Sie beispielsweise das HalloWelt-Beispiel, bei dem sich die endgültige Größe des zugehörigen Android-Anwendungspakets um 83% verringert:

• Konfiguration: Keine – Xamarin.Android 4.2.5 Größe = 17,4 MB.

• Konfiguration: Nur SDK-Assemblys – Xamarin.Android 4.2.5 Größe = 3,0 MB.

Durch das Verknüpfen können unerwartete Nebenwirkungen auftreten, daher ist es wichtig, dass eine Anwendung im Releasemodus auf einem physischen Gerät erneut getestet wird.

ProGuard

ProGuard ist ein Android SDK-Tool, das Java-Code verknüpft und verschleiert. ProGuard wird normalerweise verwendet, um kleinere Anwendungen zu erstellen, indem der Speicherbedarf für große enthaltene Bibliotheken (wie Google Play Services) in Ihrem APK reduziert wird. ProGuard entfernt nicht verwendeten Java-Bytecode, wodurch die resultierende App kleiner wird. Beispielsweise wird durch die Verwendung von ProGuard bei kleinen Xamarin.Android-Apps für gewöhnlich eine Größenreduzierung um etwa 24 % erzielt – durch die Verwendung von ProGuard bei größeren Apps mit mehreren Bibliotheksabhängigkeiten wird die Größe üblicherweise sogar noch weiter reduziert.

ProGuard ist keine Alternative zum Xamarin.Android-Linker. Der Xamarin.Android-Linker verknüpft verwalteten Code, während ProGuard Java-Bytecode verknüpft. Der Buildprozess verwendet zunächst den Xamarin.Android-Linker, um den verwalteten (C#) Code in der App zu optimieren. Anschließend nutzt er ProGuard (wenn es aktiviert ist), um das APK auf der Java-Bytecode-Ebene zu optimieren.

Wenn Enable ProGuard (ProGuard aktivieren) ausgewählt ist, führt Xamarin.Android das ProGuard-Tool auf dem resultierenden APK aus. Eine ProGuard-Konfigurationsdatei wird generiert und von ProGuard bei der Erstellung verwendet. Xamarin.Android unterstützt außerdem benutzerdefinierte ProguardConfiguration-Buildvorgänge. Sie können Ihrem Projekt eine benutzerdefinierte ProGuard-Konfigurationsdatei hinzufügen, mit der rechten Maustaste darauf klicken und sie als einen Buildvorgang auswählen, wie im folgenden Beispiel gezeigt wird:

ProGuard ist standardmäßig deaktiviert. Die Option ProGuard aktivieren ist nur dann verfügbar, wenn sich das Projekt im Modus Release befindet. Alle Buildaktionen von ProGuard werden ignoriert, wenn ProGuard deaktiviert ist. Die ProGuard-Konfiguration „Xamarin.Android“ verschleiert das APK nicht. Zudem ist es nicht möglich, die Obfuskation zu aktivieren, auch nicht mit benutzerdefinierten Konfigurationsdateien. Wenn Sie von der Obfuskation Gebrauch machen möchten, finden Sie unter Application Protection with Dotfuscator (Anwendungsschutz mit Dotfuscator) mehr Informationen.

Ausführlichere Informationen zur Verwendung des ProGuard-Tools finden Sie unter ProGuard.

Schützen der Anwendung

Deaktivieren des Debuggens

Während der Entwicklung einer Android-Anwendung wird das Debuggen mit dem Java Debug Wire Protocol (JDWP) ausgeführt. Dies ist eine Technologie, die es Tools wie adb ermöglicht, für das Debuggen mit einer JVM zu kommunizieren. JDWP ist für die Debugbuilds einer Xamarin.Android-Anwendung standardmäßig aktiviert. Obwohl JDWP während der Entwicklung wichtig ist, kann es ein Sicherheitsproblem für freigegebene Anwendungen darstellen.

Das Android-Manifest enthält das android:debuggable-Attribut, das steuert, ob die Anwendung gedebuggt werden kann oder nicht. Es wird empfohlen, das android:debuggable-Attribut auf false festzulegen. Der einfachste Weg ist das Hinzufügen einer bedingten Kompilierungsanweisung in AssemblyInfo.cs:

#if DEBUG
[assembly: Application(Debuggable=true)]
#else
[assembly: Application(Debuggable=false)]
#endif

Beachten Sie, dass Debugbuilds automatisch manche Berechtigungen festlegen, um das Debuggen zu erleichtern (z.B. Internet und ReadExternalStorage). Releasebuilds verwenden jedoch nur die Berechtigungen, die sie explizit konfigurieren. Wenn Sie feststellen, dass Ihre App durch den Wechsel zum Releasebuild eine Berechtigung verliert, die im Debugbuild verfügbar war, überprüfen Sie, dass Sie diese Berechtigung wie in Berechtigungen beschrieben explizit in der Liste Erforderliche Berechtigungen aktiviert haben.

Schützen der Anwendung mit Dotfuscator

Bündeln von Assemblys in nativem Code

Wenn diese Option aktiviert ist, werden Assemblys in einer nativen freigegebenen Bibliothek gebündelt. Dadurch können Assemblys komprimiert werden, sodass sie kleinere .apk-Dateien zulassen. Die Assemblykomprimierung überträgt außerdem eine minimale Form der Obfuskation, auf die Sie sich nicht verlassen sollten.

Diese Option erfordert eine Unternehmenslizenz und ist nur verfügbar, wenn Fast Deployment verwenden deaktiviert ist. Assemblys in nativem Code bündeln ist standardmäßig deaktiviert.

Beachten Sie, dass die Option Assemblys in nativem Code bündelnnicht bedeutet, dass die Assemblys in nativen Code kompiliert werden. Es ist nicht möglich, die AOT-Kompilierung zum Kompilieren von Assemblys in nativen Code zu verwenden.

AOT-Kompilierung

Die Option AOT Kompilierung (unter Packaging Properties (Paketeigenschaften)) aktiviert die Ahead-of-Time-Kompilierung von Assemblys. Wenn diese Option aktiviert ist, wird der Mehraufwand eines Just-In-Time-Starts minimiert, indem Assemblys vor dem Ausführen vorkompiliert werden. Der native Code, der sich daraus ergibt, ist genauso wie die nicht kompilierten Assemblys im APK enthalten. Dadurch wird zwar einerseits die Startzeit verringert, andererseits sind jedoch die APK etwas größer.

Um die Option AOT-Kompilierung ausführen zu können, müssen Sie mindestens über eine Enterprise-Lizenz verfügen. Die AOT Kompilierung ist nur verfügbar, wenn das Projekt für den Releasemodus konfiguriert ist. Sie ist standardmäßig deaktiviert. Weitere Informationen über die AOT-Kompilierung finden Sie unter AOT.

LLVM-Optimierungscompiler

Der LLVM-Optimierungscompiler erstellt kürzeren und schneller kompilierbaren Code und konvertiert AOT-kompatible Assemblys in nativen Code. Dies führt jedoch zu erhöhten Buildzeiten. Der LLVM-Compiler ist standardmäßig deaktiviert. Um den LLVM-Compiler nutzen zu können, muss zunächst auf der Seite Verpackungseigenschaften die Option AOT-Kompilierung aktiviert werden.

Festlegen von Paketeigenschaften

Viele dieser Eigenschaften, wie Shared Runtime verwenden und Fast Deployment verwenden, sind für den Debugmodus konzipiert. Wenn die Anwendung jedoch für den Releasemodus konfiguriert ist, bestimmen andere Einstellungen, wie die App für Größe und Ausführungsgeschwindigkeit optimiert wird, wie sie vor Manipulationen geschützt wird und wie sie verpackt werden kann, damit verschiedene Architekturen und Größeneinschränkungen unterstützt werden.

Angeben unterstützter Architekturen

Wenn Sie eine Xamarin.Android-App auf die Veröffentlichung vorbereiten, müssen Sie unbedingt die unterstützten CPU-Architekturen angeben. Ein einzelnes APK kann Computercode enthalten, der mehrere unterschiedliche Architekturen unterstützt. Weitere Angaben zur Unterstützung mehrere CPU-Architekturen finden Sie unter CPU-Architekturen.

Generieren eines Pakets (.APK) pro ausgewählter ABI

Wenn diese Option aktiviert ist, wird ein APK für jede der unterstützten ABIs erstellt (wird in der Erweitert-Registerkarte ausgewählt, wie in CPU Architectures (CPU-Architekturen) beschrieben), anstatt eines einzigen, großen APK für alle unterstützten ABIs. Diese Option steht nur zur Verfügung, wenn das Projekt für den Releasemodus konfiguriert ist, und sie ist standardmäßig deaktiviert.

Multi-Dex

Wenn die Option Multi-Dex aktivieren aktiviert ist, werden die Android SDK Tools dazu verwendet, das 65K-Limit für Methoden des Dateiformats .dex zu umgehen. Das 65K-Limit für Methoden basiert auf der Anzahl von Java-Methoden, auf die eine App verweist (einschließlich derer in Bibliotheken, von denen die App abhängt) – es hängt nicht von der Anzahl der Methoden ab, die im Quellcode geschrieben sind. Wenn eine Anwendung nur wenige Methoden definiert, jedoch viele (oder große Bibliotheken) verwendet, ist es möglich, dass das 65K-Limit erweitert wird.

Es ist möglich, dass eine App nicht jede Methode in jeder Bibliothek verwendet, auf die verwiesen wird. Daher ist es möglich, dass ein Tool wie ProGuard (siehe oben) die nicht verwendeten Methoden aus dem Code entfernen kann. Die bewährte Methode ist, die Option Multi-Dex aktivieren nur zu aktivieren, wenn dies unbedingt notwendig ist. D.h., dass die App selbst nach der Verwendung von ProGuard noch auf mehr als 65K Java-Methoden verweist.

Weitere Informationen zu Multi-Dex finden Sie unter Configure Apps with Over 64K Methods (Konfigurieren von Apps, die mehr als 65535 Methoden enthalten).

Android-App Bundles

App Bundles unterscheiden sich von Android-Anwendungspaketen (APKs), da sie nicht direkt auf einem Gerät bereitgestellt werden können. Stattdessen handelt es sich eher um ein Format, das mit Ihrem gesamten kompilierten Code und Ihren Ressourcen hochgeladen werden soll. Nachdem Sie das signierte App Bundle hochgeladen haben, steht für Google Play alles zur Verfügung, was benötigt wird, um die APKs Ihrer Anwendung zu erstellen und zu signieren und sie Ihren Benutzern über dynamische Bereitstellung zur Verfügung zu stellen.

Wenn Sie möchten, dass Android-App Bundles unterstützt werden, müssen Sie in den Optionen Ihres Android-Projekts die Android Package Format-Eigenschaft auf den Wert bundle festlegen. Sorgen Sie zuvor dafür, dass Sie Ihr Projekt in eine Release-Konfiguration ändern, da App Bundles nur für Releasepakete vorgesehen sind.

Sie können nun ein App Bundle erstellen, indem Sie den Archivierungsflow befolgen. Dadurch wird ein App Bundle für Ihre Anwendung erstellt.

Weitere Informationen zu Android-App Bundles finden Sie unter Informationen zu Android-App Bundles.

Compile

Archivieren zur Veröffentlichung

Verwandte Links

• Geräte mit mehreren Kernen und Xamarin.Android
• CPU-Architekturen
• AOT
• Verkleinern des Codes und der Ressourcen
• Konfigurieren von Apps, die mehr als 65535 Methoden enthalten