Freigeben über

Buildprozess

  • Artikel

Der .NET für Android-Buildprozess ist dafür verantwortlich, alles zusammen zu kleben: Generieren Resource.designer.cs, Unterstützen der @(AndroidAsset), @(AndroidResource)und anderer Buildaktionen, Generieren von Android-aufrufbaren Wrappern und Generieren einer .apk für die Ausführung auf Android-Geräten.

Anwendungspakete

Im Allgemeinen gibt es zwei Arten von Android-Anwendungspaketen (.apk Dateien), die das .NET für 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.

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 .NET für Android-Buildprozess basiert auf MSBuild, das auch das von Visual Studio für Mac und Visual Studio verwendete Projektdateiformat ist. Normalerweise müssen Benutzer die MSBuild-Dateien nicht manuell bearbeiten – die IDE erstellt voll funktionsfähige Projekte und aktualisiert sie mit änderungen, die vorgenommen wurden, und rufen automatisch Buildziele nach Bedarf 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. Diese Seite dokumentiert nur die .NET für Android-spezifischen Features und Anpassungen – 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:

Signieren von Eigenschaften

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 .NET für Android-Aufgaben keine Pakete während des Buildprozesses, da die Signierung 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>

Erstellen von Erweiterungspunkten

Das .NET für Android-Buildsystem macht einige öffentliche Erweiterungspunkte für Benutzer verfügbar, die in unseren Buildprozess eingebunden werden 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:

Ein Wort mit Vorsicht beim Erweitern des Buildprozesses: Wenn sie nicht ordnungsgemäß geschrieben wurden, können Builderweiterungen die Buildleistung beeinflussen, insbesondere, wenn sie auf jedem Build ausgeführt werden. Es wird dringend empfohlen, vor der Implementierung solcher Erweiterungen die MSBuild-Dokumentation zu lesen.

Zieldefinitionen

Die .NET für Android-spezifischen Teile des Buildprozesses sind in $(MSBuildExtensionsPath)\Xamarin\Android\Xamarin.Android.CSharp.targetsdefiniert, aber normale sprachspezifische Ziele wie Microsoft.CSharp.targets sind ebenfalls 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.