Buildprozess

Artikel
07/13/2023

Der Xamarin.Android-Buildprozess ist dafür verantwortlich, alles zusammenzufügen: Generieren von Resource.designer.cs, Unterstützen von @(AndroidAsset), @(AndroidResource) und anderen Buildaktionen, Generieren von Wrappern, die von Android aufgerufen werden können, und Generieren einer .apk-Datei für die Ausführung auf Android-Geräten.

Anwendungspakete

Im Großen und Ganzen gibt es zwei Arten von Android-Anwendungspaketen (.apk-Dateien), die das Xamarin.Android-Buildsystem generieren kann:

Releasebuilds, die vollkommen eigenständig sind und keine zusätzlichen Pakete benötigen, um ausgeführt werden zu können. Dies sind die Pakete, die App-Stores zur Verfügung gestellt werden.
Debugbuilds, auf die dies nicht zutrifft.

Diese Pakettypen entsprechen der MSBuild-Configuration, mit der das Paket erstellt wird.

Shared Runtime

Vor Xamarin.Android 11.2 handelte es sich bei der Shared Runtime um zwei zusätzliche Android-Pakete, die die Basisklassenbibliothek (mscorlib.dll usw.) und die Android-Bindungsbibliothek (Mono.Android.dll usw.) bereitstellten. Debugbuilds verwenden die Shared Runtime, anstatt die Basisklassenbibliothek und Bindungsassemblys in das Android-Anwendungspaket einzubinden, wodurch das Debugpaket kleiner wird.

Die Shared Runtime konnte in Debugbuilds deaktiviert werden, indem die -Eigenschaft$(AndroidUseSharedRuntime) -Eigenschaft für False.

Die Unterstützung für die Shared Runtime wurde in Xamarin.Android 11.2 eingestellt.

Schnelle Bereitstellung

Bei der schnellen Bereitstellung wird die Größe des Android-Anwendungspakets weiter verkleinert. Hierzu werden die Assemblys der App aus dem Paket ausgeschlossen und stattdessen direkt im internen files-Verzeichnis der Anwendung bereitgestellt, das sich in der Regel unter /data/data/com.some.package befindet. Das interne files-Verzeichnis ist kein global beschreibbarer Ordner. Daher werden alle Befehle zum Kopieren der Dateien in dieses Verzeichnis über das Tool run-as ausgeführt.

Dieser Prozess beschleunigt den Build-/Bereitstellungs-/Debugzyklus, da das Paket nicht erneut installiert wird, wenn nur Assemblys geändert werden. Stattdessen werden nur die aktualisierten Assemblys erneut mit dem Zielgerät synchronisiert.

Warnung

Es ist bekannt, dass bei der schnellen Bereitstellung bei Geräten, die run-as blockieren, ein Fehler auftritt. Dies betrifft oft Geräte mit einer älteren Android-Version als 5.0.

Die schnelle Bereitstellung ist standardmäßig aktiviert und kann in Debugbuilds deaktiviert werden, indem die $(EmbedAssembliesIntoApk)-Eigenschaft auf True festgelegt wird.

Der Modus für eine erweiterte schnelle Bereitstellung kann zusammen mit diesem Feature verwendet werden, um Bereitstellungen noch weiter zu beschleunigen. Dadurch werden Assemblys, native Bibliotheken, Typzuordnungen und DEX-Dateien im files-Verzeichnis bereitgestellt. Das Aktivieren dieser Option sollte jedoch nur erforderlich sein, wenn Sie native Bibliotheken, Bindungen oder Java-Code ändern.

MSBuild-Projekte

Der Xamarin.Android-Buildprozess basiert auf MSBuild, dem Projektdateiformat, das auch von Visual Studio für Mac und Visual Studio verwendet wird. Normalerweise müssen Benutzer die MSBuild-Dateien nicht manuell bearbeiten . Die IDE erstellt voll funktionsfähige Projekte und aktualisiert sie mit den vorgenommenen Änderungen und ruft bei Bedarf automatisch Buildziele auf.

Fortgeschrittene Benutzer möchten vielleicht Aktionen ausführen, die nicht von der GUI der IDE unterstützt werden, sodass der Buildprozess durch direktes Bearbeiten der Projektdatei angepasst werden kann. Auf dieser Seite werden nur die Xamarin.Android-spezifischen Features und Anpassungen dokumentiert – viele weitere Dinge sind mit den normalen MSBuild-Elementen, -Eigenschaften und -Zielen möglich.

Bindungsprojekte

Die folgenden MSBuild-Eigenschaften werden mit Bindungsprojekten verwendet:

Generierung der Datei `Resource.designer.cs`

Mithilfe der folgenden MSBuild-Eigenschaften wird die Generierung der Datei Resource.designer.cs gesteuert:

Signatureigenschaften

Signatureigenschaften steuern, wie das Anwendungspaket signiert wird, damit es auf einem Android-Gerät installiert werden kann. Um eine schnellere Builditeration zu ermöglichen, signieren die Xamarin.Android-Tasks während des Buildprozesses keine Pakete, da das Signieren recht langsam ist. Stattdessen werden sie (wenn erforderlich) vor der Installation oder während des Exports von der IDE oder dem Buildziel Install signiert. Wenn Sie das Ziel SignAndroidPackage aufrufen, wird ein Paket mit dem Suffix -Signed.apk im Ausgabeverzeichnis generiert.

Standardmäßig generiert das Signaturziel bei Bedarf einen neuen Debugsignaturschlüssel. Wenn Sie einen bestimmten Schlüssel verwenden möchten (z. B. auf einem Buildserver), verwenden Sie die folgenden MSBuild-Eigenschaften:

Zuordnung der `keytool`-Option

Betrachten Sie den folgenden Aufruf von keytool:

$ keytool -genkey -v -keystore filename.keystore -alias keystore.alias -keyalg RSA -keysize 2048 -validity 10000
Enter keystore password: keystore.filename password
Re-enter new password: keystore.filename password
...
Is CN=... correct?
  [no]:  yes

Generating 2,048 bit RSA key pair and self-signed certificate (SHA1withRSA) with a validity of 10,000 days
        for: ...
Enter key password for keystore.alias
        (RETURN if same as keystore password): keystore.alias password
[Storing filename.keystore]

Um den oben generierten Keystore zu verwenden, verwenden Sie die Eigenschaftengruppe:

<PropertyGroup>
    <AndroidKeyStore>True</AndroidKeyStore>
    <AndroidSigningKeyStore>filename.keystore</AndroidSigningKeyStore>
    <AndroidSigningStorePass>keystore.filename password</AndroidSigningStorePass>
    <AndroidSigningKeyAlias>keystore.alias</AndroidSigningKeyAlias>
    <AndroidSigningKeyPass>keystore.alias password</AndroidSigningKeyPass>
</PropertyGroup>

Builderweiterungspunkte

Das Xamarin.Android-Buildsystem stellt einige öffentliche Erweiterungspunkte für Benutzer zur Verfügung, die von unserem Buildprozess profitieren möchten. Damit Sie diese Erweiterungspunkte verwenden können, müssen Sie der entsprechenden MSBuild-Eigenschaft in einer PropertyGroup ein benutzerdefiniertes Ziel hinzufügen. Zum Beispiel:

<PropertyGroup>
   <AfterGenerateAndroidManifest>
      $(AfterGenerateAndroidManifest);
      YourTarget;
   </AfterGenerateAndroidManifest>
</PropertyGroup>

Erweiterungspunkte umfassen:

Sie sollten bei der Verwendung von Builderweiterungen Vorsicht walten lassen. Wenn eine Builderweiterung einen Fehler enthält, kann dies Auswirkungen auf die Buildleistung haben. Dies ist insbesondere dann der Fall, wenn die Erweiterung für alle Builds verwendet wird. Es wird dringend empfohlen, vor der Implementierung solcher Erweiterungen die MSBuild-Dokumentation zu lesen.

Zieldefinitionen

Die für Xamarin.Android spezifischen Teile des Buildprozesses werden in $(MSBuildExtensionsPath)\Xamarin\Android\Xamarin.Android.CSharp.targets definiert, aber auch normale sprachspezifische Ziele wie Microsoft.CSharp.targets sind erforderlich, um die Assembly zu erstellen.

Die folgenden Buildeigenschaften müssen vor dem Importieren von Sprachzielen festgelegt werden:

<PropertyGroup>
  <TargetFrameworkIdentifier>MonoDroid</TargetFrameworkIdentifier>
  <MonoDroidVersion>v1.0</MonoDroidVersion>
  <TargetFrameworkVersion>v2.2</TargetFrameworkVersion>
</PropertyGroup>

Alle diese Ziele und Eigenschaften können für C# durch Importieren von Xamarin.Android.CSharp.targets eingebunden werden:

<Import Project="$(MSBuildExtensionsPath)\Xamarin\Android\Xamarin.Android.CSharp.targets" />

Diese Datei kann problemlos für andere Sprachen angepasst werden.