Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Nachdem eine Anwendung codiert und getestet wurde, müssen Sie ein Paket für die Verteilung vorbereiten. Die erste Aufgabe beim Vorbereiten dieses Pakets besteht darin, die Anwendung für die Veröffentlichung zu erstellen, die hauptsächlich das Festlegen einiger Anwendungsattribute erfordert.
Führen Sie die folgenden Schritte aus, um die App für die Veröffentlichung zu erstellen:
Geben Sie das Anwendungssymbol an– Jede Xamarin.Android-Anwendung sollte ein Anwendungssymbol angegeben haben. Obwohl nicht technisch notwendig, erfordern einige Märkte, wie z. B. Google Play, sie.
Version der Anwendung – Dieser Schritt umfasst das Initialisieren oder Aktualisieren der Versionsverwaltungsinformationen. Dies ist wichtig für zukünftige Anwendungsupdates und um sicherzustellen, dass die Benutzer wissen, welche Version der Anwendung sie installiert haben.
Verkleinern Sie die APK – Die Größe der endgültigen APK kann erheblich reduziert werden, indem sie den Xamarin.Android-Linker im verwalteten Code und ProGuard auf dem Java-Bytecode verwenden.
Schützen Sie die Anwendung – Verhindern Sie, dass Benutzer oder Angreifer die Anwendung debuggen, manipulieren oder reverse engineering, indem Sie das Debuggen deaktivieren, den verwalteten Code verschleiern, Antidebugging und Antimanipulationen hinzufügen und die systemeigene Kompilierung verwenden.
Festlegen von Verpackungseigenschaften – Verpackungseigenschaften steuern die Erstellung des Android-Anwendungspakets (APK). Dieser Schritt optimiert die APK, schützt seine Ressourcen und modularisiert die Verpackung nach Bedarf. Darüber hinaus können Sie Ihren Benutzern ein Android-App-Bündel bereitstellen, das für ihre Geräte optimiert ist.
Kompilieren – Dieser Schritt kompiliert den Code und die Ressourcen, um zu überprüfen, ob er im Releasemodus erstellt wird.
Archiv für Veröffentlichung – Dieser Schritt erstellt die App und platziert sie in einem Archiv zum Signieren und Veröffentlichen.
Jede dieser Schritte wird im Folgenden ausführlicher beschrieben.
Angeben des Anwendungssymbols
Es wird dringend empfohlen, dass jede Xamarin.Android-Anwendung ein Anwendungssymbol angibt. Einige Anwendungs-Marketplaces erlauben nicht, dass eine Android-Anwendung ohne eine veröffentlicht wird. Die Icon Eigenschaft des Application Attributs wird verwendet, um das Anwendungssymbol für ein Xamarin.Android-Projekt anzugeben.
Geben Sie in Visual Studio 2017 und höher das Anwendungssymbol über den Android-Manifestabschnitt der Projekteigenschaften an, wie im folgenden Screenshot gezeigt:
In diesen Beispielen bezieht sich @drawable/icon auf eine Symboldatei, die sich unter Resources/drawable/icon.png befindet (beachten Sie, dass die .png-Erweiterung nicht im Ressourcennamen enthalten ist). Dieses Attribut kann auch in der Datei "Properties\AssemblyInfo.cs" deklariert werden, wie in diesem Beispielausschnitt gezeigt:
[assembly: Application(Icon = "@drawable/icon")]
using Android.App Normalerweise wird oben in AssemblyInfo.cs deklariert (der Namespace des Application Attributs istAndroid.App); Sie müssen diese using Anweisung jedoch ggf. hinzufügen, wenn sie noch nicht vorhanden ist.
Versionieren der Anwendung
Die Versionsverwaltung ist für die Wartung und Verteilung von Android-Anwendungen wichtig. Ohne eine Art von Versionsverwaltung ist es schwierig zu ermitteln, ob oder wie eine Anwendung aktualisiert werden soll. Um die Versionsverwaltung zu unterstützen, erkennt Android zwei verschiedene Arten von Informationen:
Versionsnummer – Ein ganzzahliger Wert (intern von Android und der Anwendung verwendet), der die Version der Anwendung darstellt. Die meisten Anwendungen beginnen mit diesem Wert, der auf 1 festgelegt ist, und dann wird sie mit jedem Build erhöht. Dieser Wert hat keine Beziehung oder Affinität mit dem Versionsnamenattribut (siehe unten). Anwendungen und Veröffentlichungsdienste sollten diesen Wert nicht für Benutzer anzeigen. Dieser Wert wird in der AndroidManifest.xml Datei als
android:versionCodegespeichert.Versionsname – Eine Zeichenfolge, die nur für die Kommunikation von Informationen an den Benutzer über die Version der Anwendung verwendet wird (wie auf einem bestimmten Gerät installiert). Der Versionsname soll Benutzern oder in Google Play angezeigt werden. Diese Zeichenfolge wird nicht intern von Android verwendet. Der Versionsname kann ein beliebiger Zeichenfolgenwert sein, der einem Benutzer hilft, den Build zu identifizieren, der auf dem Gerät installiert ist. Dieser Wert wird in der AndroidManifest.xml Datei als
android:versionNamegespeichert.
In Visual Studio können diese Werte im Android-Manifestabschnitt der Projekteigenschaften festgelegt werden, wie im folgenden Screenshot gezeigt:
Verkleinern sie die APK
Xamarin.Android-APKs können durch eine Kombination aus dem Xamarin.Android-Linker verkleinert werden, der unnötigen verwalteter Code entfernt, und dem ProGuard-Tool aus dem Android SDK, das nicht verwendeten Java-Bytecode entfernt. Der Buildprozess verwendet zuerst den Xamarin.Android-Linker, um die App auf C#-Ebene (managed code) zu optimieren, und dann verwendet er später ProGuard (sofern aktiviert), um die APK auf Java-Bytecode-Ebene zu optimieren.
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 verwendet statische Analysen, um zu bestimmen, 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 zum Beispiel das HelloWorld-Beispiel , das eine Reduzierung von 83% in der endgültigen Größe seiner APK erlebt:
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.
Legen Sie Linkeroptionen über den Abschnitt Android-Optionen der Projekteigenschaften fest:
Das Pulldownmenü Verknüpfen enthält die folgenden Optionen zum Steuern des Linkers:
Keine – Dadurch wird der Linker deaktiviert; Es wird keine Verknüpfung ausgeführt.
Nur SDK-Assemblys – Dadurch werden nur die Assemblys verknüpft, die von Xamarin.Android benötigt werden. Andere Assemblys werden nicht verknüpft.
Sdk- und Benutzerassemblys – Dadurch werden alle Assemblys verknüpft, die von der Anwendung benötigt werden, und nicht nur die Assemblys, die von Xamarin.Android benötigt werden.
Verknüpfungen können zu unbeabsichtigten Nebenwirkungen führen, 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 großer enthaltener Bibliotheken (z. B. Google Play Services) in Ihrem APK reduziert wird. ProGuard entfernt nicht verwendete Java-Bytecode, wodurch die resultierende App kleiner wird. Beispielsweise erzielt die Verwendung von ProGuard auf kleinen Xamarin.Android-Apps in der Regel etwa eine Verringerung der Größe von 24% – die Verwendung von ProGuard für größere Apps mit mehreren Bibliotheksabhängigkeiten erzielt in der Regel eine noch größere Größenreduzierung.
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 zuerst den Xamarin.Android-Linker, um den verwalteten Code (C#) in der App zu optimieren, und dann verwendet er später ProGuard (sofern aktiviert), um die APK auf Java-Bytecode-Ebene zu optimieren.
Wenn "ProGuard aktivieren" aktiviert ist, führt Xamarin.Android das ProGuard-Tool auf dem resultierenden APK aus. Während der Erstellung wird eine ProGuard-Konfigurationsdatei generiert und von ProGuard verwendet. Xamarin.Android unterstützt auch benutzerdefinierte ProguardConfiguration-Buildaktionen . Sie können Ihrem Projekt eine benutzerdefinierte ProGuard-Konfigurationsdatei hinzufügen, mit der rechten Maustaste darauf klicken und als Buildaktion auswählen, wie in diesem Beispiel gezeigt:
ProGuard ist standardmäßig deaktiviert. Die Option "ProGuard aktivieren" ist nur verfügbar, wenn das Projekt auf den Releasemodus festgelegt ist. Alle Buildaktionen von ProGuard werden ignoriert, wenn ProGuard deaktiviert ist. Die Xamarin.Android ProGuard-Konfiguration verschleiert die APK nicht, und es ist nicht möglich, obfuscation zu aktivieren, auch bei 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 der Verwendung des Java Debug Wire Protocol (JDWP) durchgeführt. Dies ist eine Technologie, mit der Tools wie adb zum Debuggen mit einem JVM kommunizieren können. JDWP ist standardmäßig für Debugbuilds einer Xamarin.Android-Anwendung aktiviert. Während JDWP während der Entwicklung wichtig ist, kann es ein Sicherheitsproblem für veröffentlichte Anwendungen darstellen.
Von Bedeutung
Deaktivieren Sie den Debugstatus in einer freigegebenen Anwendung immer so, wie es möglich ist (über JDWP), vollzugriff auf den Java-Prozess zu erhalten und beliebigen Code im Kontext der Anwendung auszuführen, wenn dieser Debugstatus nicht deaktiviert ist.
Das Android-Manifest enthält das android:debuggable Attribut, das steuert, ob die Anwendung gedebuggt werden kann. Es wird als bewährte Methode angesehen, das Attribut android:debuggable auf false festzulegen. Die einfachste Möglichkeit hierfür 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 einige Berechtigungen festlegen, um das Debuggen zu vereinfachen (z. B. Internet und ReadExternalStorage). Releasebuilds verwenden jedoch nur die Berechtigungen, die Sie explizit konfigurieren. Wenn Sie feststellen, dass der Wechsel zum Releasebuild bewirkt, dass Ihre App eine Berechtigung verliert, die im Debugbuild verfügbar war, stellen Sie sicher, dass Sie diese Berechtigung explizit in der Liste der erforderlichen Berechtigungen aktiviert haben, wie in "Berechtigungen" beschrieben.
Schützen der Anwendung mit Dotfuscator
Selbst wenn das Debuggen deaktiviert ist, können Angreifer eine Anwendung erneut packen, Konfigurationsoptionen oder Berechtigungen hinzufügen oder entfernen. Auf diese Weise können sie die Anwendung rückgängig machen, debuggen oder manipulieren. Dotfuscator Community Edition (CE) kann verwendet werden, um verwalteten Code zu verschleiern und Laufzeitsicherheitsstatuserkennungscode zur Erstellungszeit in eine Xamarin.Android-App einzufügen, um zu erkennen und darauf zu reagieren, wenn die App auf einem gerooteten Gerät ausgeführt wird.
Dotfuscator CE ist in Visual Studio 2017 enthalten. Um Dotfuscator zu verwenden, klicken Sie auf Tools > PreEmptive Protection - Dotfuscator.
Informationen zum Konfigurieren von Dotfuscator CE finden Sie unter Verwenden der Dotfuscator Community Edition mit Xamarin. Nach der Konfiguration schützt Dotfuscator CE automatisch jeden erstellten Build.
Bündeln von Assemblys in nativem Code
Wenn diese Option aktiviert ist, werden Assemblys in einer nativen freigegebenen Bibliothek gebündelt. Auf diese Weise können Assemblys komprimiert werden, wodurch kleinere .apk Dateien zulässig sind. Die Assemblykomprimierung überträgt außerdem eine minimale Form der Obfuskation, auf die Sie sich nicht verlassen sollten.
Diese Option erfordert eine Enterprise-Lizenz und ist nur verfügbar, wenn "Schnelle Bereitstellung verwenden " deaktiviert ist. Bundle Assemblies in nativen Code ist standardmäßig deaktiviert.
Beachten Sie, dass die Option "In systemeigenem Code bündeln " nicht bedeutet, dass die Assemblys in systemeigenem Code kompiliert werden. Es ist nicht möglich, die AOT-Kompilierung zum Kompilieren von Assemblys in systemeigenem 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 Startaufwand von Just In Time (JIT) durch Vorkompilierung von Assemblys vor der Laufzeit minimiert. Der resultierende native Code ist zusammen mit den nicht kompilierten Assemblys im APK enthalten. Dies führt zu einer kürzeren Startzeit der Anwendung, aber auf Kosten von etwas größeren APK-Größen.
Für die AOT-Kompilierungsoption ist eine Enterprise-Lizenz oder höher erforderlich. AOT-Kompilierung ist nur verfügbar, wenn das Projekt für den Releasemodus konfiguriert ist und standardmäßig deaktiviert ist. Weitere Informationen zur AOT-Kompilierung finden Sie unter AOT.
LLVM-Optimierungscompiler
Der LLVM-Optimierungscompiler erstellt kleineren und schneller kompilierten Code und konvertiert AOT-kompilierte Assemblys in systemeigenen Code, aber auf Kosten langsamerer Buildzeiten. Der LLVM-Compiler ist standardmäßig deaktiviert. Um den LLVM-Compiler zu verwenden, muss die AOT-Kompilierungsoption zuerst aktiviert sein (auf der Seite " Verpackungseigenschaften ").
Hinweis
Für die LLVM-Compileroptimierungsoption ist eine Enterprise-Lizenz erforderlich.
Festlegen von Verpackungseigenschaften
Verpackungseigenschaften können im Abschnitt "Android-Optionen " der Projekteigenschaften festgelegt werden, wie im folgenden Screenshot gezeigt:
Viele dieser Eigenschaften, z. B. "Freigegebene Runtime verwenden" und "Schnelle Bereitstellung verwenden " sind für den Debugmodus vorgesehen. Wenn die Anwendung jedoch für den Releasemodus konfiguriert ist, gibt es weitere Einstellungen, die bestimmen, wie die App für die Größen- und Ausführungsgeschwindigkeit optimiertist, wie sie vor Manipulationen geschützt ist und wie sie verpackt werden kann, um unterschiedliche Architekturen und Größenbeschränkungen zu unterstützen.
Angeben unterstützter Architekturen
Beim Vorbereiten einer Xamarin.Android-App für die Veröffentlichung ist es erforderlich, die unterstützten CPU-Architekturen anzugeben. Ein einzelnes APK kann Computercode enthalten, um mehrere, unterschiedliche Architekturen zu unterstützen. Weitere Informationen zur Unterstützung mehrerer CPU-Architekturen finden Sie unter CPU-Architekturen .
Generieren eines Pakets (.APK) pro ausgewählter ABI
Wenn diese Option aktiviert ist, wird für jede der unterstützten ABIs (ausgewählt auf der Registerkarte Erweitert und beschrieben in CPU-Architekturen) ein APK erzeugt, anstelle einer einzigen großen APK für alle unterstützten ABIs. Diese Option ist nur verfügbar, wenn das Projekt für den Versionsmodus konfiguriert ist und standardmäßig deaktiviert ist.
Multi-Dex
Wenn die Option "Multi-Dex aktivieren" aktiviert ist, werden Android SDK-Tools verwendet, um das 65K-Methodenlimit des DEX-Dateiformats zu umgehen. Die Einschränkung der 65K-Methode basiert auf der Anzahl der Java-Methoden, auf die eine App verweist (einschließlich derjenigen in bibliotheken, von denen die App abhängt) – sie basiert nicht auf der Anzahl der Methoden, die im Quellcode geschrieben wurden. Wenn eine Anwendung nur einige Methoden definiert, aber viele (oder große Bibliotheken) verwendet, ist es möglich, dass der Grenzwert von 65 KB überschritten 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 Code entfernen kann. Die bewährte Methode ist die Aktivierung von Multi-Dex nur, wenn dies unbedingt erforderlich ist, d.h., dass die App auch nach der Verwendung von ProGuard immer noch mehr als 65K Java-Methoden referenziert.
Weitere Informationen zu Multi-Dex finden Sie unter Konfigurieren von Apps mit Über 64K-Methoden.
Android-App-Bündel
App-Bündel unterscheiden sich von APKs, da sie nicht direkt auf einem Gerät bereitgestellt werden können. Stattdessen ist es ein Format, das mit allen kompilierten Code und Ressourcen hochgeladen werden soll. Nachdem Sie Ihr signiertes App-Bündel hochgeladen haben, verfügt Google Play über alles, was sie zum Erstellen und Signieren der APKs Ihrer Anwendung benötigt, und sie ihren Benutzern mithilfe der dynamischen Übermittlung bereitstellen.
Um die Unterstützung für Android-App-Bündel zu aktivieren, müssen Sie die bundle Einstellung der Android-Paketformateigenschaft innerhalb Ihrer Android-Projektoptionen auswählen. Bevor Sie dies tun, stellen Sie sicher, dass Sie Ihr Projekt in eine Release Konfiguration ändern, da App-Bündel nur für Releasepakete vorgesehen sind.
Sie können jetzt ein App-Bündel generieren, indem Sie dem Archivfluss folgen. Dadurch wird ein App-Bündel für Ihre Anwendung generiert.
Weitere Informationen zu Android-App-Bündeln finden Sie unter Android-App-Bündel.
Kompilieren
Nachdem alle oben genannten Schritte abgeschlossen wurden, ist die App für die Kompilierung bereit. Wählen Sie "Lösung > neu erstellen" aus, um zu überprüfen, ob sie erfolgreich im Releasemodus erstellt werden kann. Beachten Sie, dass dieser Schritt noch keine APK erzeugt.
Das Signieren des App-Pakets erläutert das Verpacken und Signieren ausführlicher.
Archivieren zur Veröffentlichung
Klicken Sie zum Starten des Veröffentlichungsprozesses im Projektmappen-Explorer mit der rechten Maustaste auf das Projekt, und wählen Sie das Kontextmenüelement "Archiv... " aus:
Archiv... startet den Archiv-Manager und beginnt mit der Archivierung des App-Bündels, wie in diesem Screenshot gezeigt:
Eine weitere Möglichkeit, ein Archiv zu erstellen, besteht darin, im Lösungs-Explorer mit der rechten Maustaste auf die Lösung zu klicken und Alles archivieren... auszuwählen. Dadurch wird die Lösung erstellt und alle Xamarin-Projekte, die ein Archiv erstellen können, werden archiviert.
Sowohl "Archivieren " als auch " Alle archivieren " starten automatisch den Archiv-Manager. Um den Archiv-Manager direkt zu starten, klicken Sie auf das Menüelement Tools> Archiv-Manager...
Die Archive der Lösung können jederzeit durch Klicken mit der rechten Maustaste auf den Lösungsknoten und Auswählen von 'Archiv anzeigen' aufgerufen werden.
Der Archiv-Manager
Der Archiv-Manager besteht aus einem Lösungslistenbereich , einer Archivliste und einem Detailbereich:
In der Projektmappenliste werden alle Lösungen mit mindestens einem archivierten Projekt angezeigt. Die Lösungsliste enthält die folgenden Abschnitte:
- Aktuelle Lösung – Zeigt die aktuelle Lösung an. Beachten Sie, dass dieser Bereich möglicherweise leer ist, wenn die aktuelle Lösung nicht über ein vorhandenes Archiv verfügt.
- Alle Archive – Zeigt alle Lösungen an, die über ein Archiv verfügen.
- Suchtextfeld (oben) – Filtert die in der Liste "Alle Archive " aufgeführten Lösungen gemäß der im Textfeld eingegebenen Suchzeichenfolge.
In der Archivliste wird die Liste aller Archive für die ausgewählte Lösung angezeigt. Die Archivliste enthält die folgenden Abschnitte:
- Ausgewählter Lösungsname – Zeigt den Namen der Lösung an, die in der Lösungsliste ausgewählt ist. Alle in der Archivliste angezeigten Informationen beziehen sich auf diese ausgewählte Lösung.
- Platforms Filter – Dieses Feld ermöglicht das Filtern von Archiven nach Plattformtyp (z. B. iOS oder Android).
- Archivelemente – Liste der Archive für die ausgewählte Lösung. Jedes Element in dieser Liste enthält den Projektnamen, das Erstellungsdatum und die Plattform. Sie kann auch zusätzliche Informationen anzeigen, z. B. den Fortschritt, wenn ein Element archiviert oder veröffentlicht wird.
Im Detailbereich werden zusätzliche Informationen zu den einzelnen Archiven angezeigt. Außerdem kann der Benutzer den Verteilungsworkflow starten oder den Ordner öffnen, in dem die Verteilung erstellt wurde. Der Abschnitt " Buildkommentare " ermöglicht das Einfügen von Buildkommentaren in das Archiv.
Verteilung
Wenn eine archivierte Version der Anwendung zum Veröffentlichen bereit ist, wählen Sie das Archiv im Archiv-Manager aus, und klicken Sie auf die Schaltfläche " Verteilen... ":
Im Dialogfeld "Verteilungskanal " werden Informationen zur App, ein Hinweis auf den Fortschritt des Verteilungsworkflows und eine Auswahl von Vertriebskanälen angezeigt. Bei der ersten Ausführung werden zwei Optionen angezeigt:
Es ist möglich, einen der folgenden Vertriebskanäle auszuwählen:
Ad-Hoc – Speichert ein signiertes APK auf einem Datenträger, der auf Android-Geräten quergeladen werden kann. Fahren Sie mit dem Signieren des App-Pakets fort, um zu erfahren, wie Sie eine Android-Signaturidentität erstellen, ein neues Signaturzertifikat für Android-Anwendungen erstellen und eine Ad-hoc-Version der App auf einem Datenträger veröffentlichen. Dies ist eine gute Möglichkeit, ein APK zum Testen zu erstellen.
Google Play – Veröffentlicht eine signierte APK bei Google Play. Fahren Sie mit der Veröffentlichung in Google Play fort, um zu erfahren, wie Sie eine APK im Google Play Store signieren und veröffentlichen.
