Partager via

Création d’applications Xamarin pour Android

  • Article

Important

La mise hors service de Visual Studio App Center est prévue pour le 31 mars 2025. Bien que vous puissiez continuer à utiliser Visual Studio App Center jusqu’à sa mise hors service complète, il existe plusieurs alternatives recommandées vers lesquelles vous pouvez envisager la migration.

En savoir plus sur les chronologies et les alternatives de support.

Pour commencer à créer votre première application Android Xamarin, vous devez :

  1. Connectez-vous à votre compte de service de dépôt (GitHub, Bitbucket, VSTS, Azure DevOps).
  2. Sélectionnez un dépôt et une branche où réside votre application.
  3. Choisissez le projet Android que vous souhaitez générer.
  4. Configurez votre première build.

Notes

Pour que l’application s’exécute sur un appareil réel, vous devez signer la build avec un magasin de clés valide.

1. Liaison de votre dépôt

Si vous ne vous êtes pas déjà connecté à votre compte de service de dépôt, vous devez d’abord le faire. Une fois votre compte connecté, sélectionnez le dépôt où se trouve votre projet Xamarin. Vous devez disposer des autorisations d’administrateur et d’extraction pour configurer une build pour un dépôt.

2. Sélection d’une branche

Après avoir sélectionné un dépôt, sélectionnez la branche que vous souhaitez générer. Par défaut, App Center répertorie toutes les branches actives.

3. Configuration de votre build

Le projet Xamarin doit être configuré avant votre première build.

3.1. Déclencheurs de génération

Par défaut, le service de build utilise l’intégration continue, de sorte qu’une nouvelle build est déclenchée chaque fois qu’un développeur envoie (push) à une branche configurée. Si vous préférez déclencher de nouvelles builds manuellement, vous pouvez modifier ce paramètre dans le volet de configuration.

3.2. Projet et configuration

Les projets disponibles dans votre dépôt sont renseignés s’ils se trouvent dans la plage d’analyse. Sélectionnez le projet approprié pour votre build Android, puis sélectionnez la configuration appropriée.

Notes

Pour de meilleures performances, l’analyse est actuellement limitée à quatre niveaux de répertoire, y compris la racine de votre dépôt.

3.3. Version mono

App Center permet d’utiliser différents environnements Mono fournis avec le SDK Xamarin.Android respectif pour vos builds. De cette façon, nous maintenons la compatibilité descendante tout en prenant en charge les dernières fonctionnalités. La version Mono par défaut d’une nouvelle configuration de branche est la dernière version stable. Vous pouvez choisir d’utiliser l’un des environnements Mono précédents pour créer des versions plus anciennes de frameworks ou de bibliothèques.

Lors de la sélection d’une version Mono dans la configuration de build, la version groupée du SDK Xamarin.Android s’affiche juste à côté de celle-ci. Pour plus d’informations sur les mises à jour de la version du SDK Xamarin, consultez le blog de publication de Xamarin.

3.3.1. Version .NET Core

La version appropriée de .NET Core est sélectionnée automatiquement en fonction de la version Mono utilisée pour la génération et ne peut pas être remplacée. Vous pouvez afficher le mappage de Mono au .NET Core utilisé par nos services dans le tableau ci-dessous :

Mono .NET Core
<= 5,18 2.2.105
6.0 2.2.300
6.4 3.0.100
6.6 3.1.100
6.8 3.1.200
6.10 3.1.300
6.12 3.1.401

3.4. Générer un ensemble d’applications Android (.aab)

L’offre groupée d’applications Android est un format de distribution utilisé pour générer des KITS API optimisés pour des appareils spécifiques. Il peut être chargé sur le Play Store. Vous pouvez en savoir plus sur l’offre groupée d’applications Android dans la documentation Android officielle et les notes de publication de Xamarin.Android 9.4, qui peuvent également vous aider à décider si vous souhaitez créer un bundle avec votre offre standard .apk.

Activez l’option pour android App Bundle pour produire un .aab et un .apk. Si le .csproj fichier contient aab dans la AndroidPackageFormat propriété , cette option est automatiquement activée. La création d’un .aab est prise en charge pour Xamarin.Android 9.4 et versions ultérieures.

3.5. Incrémenter le numéro de version

Quand cette option est activée, le code de version dans le AndroidManifest.xml de votre application s’incrémente automatiquement pour chaque build. La modification se produit avant la génération et ne sera pas validée dans votre dépôt.

3.6. Signature de code

Une génération réussie génère un .apk fichier et un fichier supplémentaire .aab si cette option est activée. Pour libérer la build sur le Play Store, elle doit être signée avec un magasin de clés et un alias valides. Pour signer les builds produites à partir d’une branche, activez la signature du code dans le volet de configuration, chargez votre magasin de clés et fournissez les valeurs nécessaires dans le volet de configuration. Vous pouvez lire des instructions de signature de code plus détaillées. le .aab sera signé à l’aide des mêmes informations d’identification que ..apk

3.7. Lancer votre build réussie sur un appareil réel

Utilisez votre fichier nouvellement produit .apk pour tester si votre application démarre sur un appareil réel. Cela ajoute environ 10 minutes de plus au temps de génération total. Vous trouverez plus d’informations dans notre guide d’intégration des tests.

3.8. Restauration NuGet

Si le NuGet.config fichier est archivé dans le dépôt et se trouve à côté du .sln fichier ou au niveau racine de votre dépôt, App Center restaure vos flux NuGet privés lorsqu’ils sont ajoutés, comme indiqué dans l’exemple ci-dessous. Les informations d’identification peuvent être ajoutées en toute sécurité à l’aide de variables d’environnement :

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <add key="nuget" value="https://api.nuget.org/v3/index.json" />
    <add key="MyGet" value="https://www.myget.org/F/MyUsername/api/v2/index.json" />
    <add key="MyAuthNuget" value="https://nuget.example.com/v2/index.json" />
  </packageSources>
  <activePackageSource>
    <add key="All" value="(Aggregate source)" />
  </activePackageSource>
  <packageSourceCredentials>
    <MyAuthNuget>
      <add key="Username" value="$USER_VARIABLE" />
      <add key="ClearTextPassword" value="$PASSWORD_VARIABLE" />
    </MyAuthNuget>
  </packageSourceCredentials>
</configuration>

Si vous avez des configurations complexes et que vous avez besoin d’informations supplémentaires, consultez Configuration du comportement de NuGet.

3.9. Distribuer la build

Vous pouvez configurer chaque build réussie à partir d’une branche pour qu’elle soit distribuée à un groupe de distribution créé précédemment ou à une destination de magasin. Vous pouvez ajouter un nouveau groupe de distribution ou configurer une connexion au magasin à partir du service Distribution. Il existe toujours un groupe de distribution par défaut appelé « Collaborateurs » qui inclut tous les utilisateurs qui ont accès à l’application.

Notes

En cas de distribution dans le Google Play Store, un ensemble d’applications Android (.aab) est préféré et sera distribué s’il est activé. Pour les groupes de distribution App Center et les destinations de Intune store, un standard .apk est utilisé même si un .aab est également généré.

4. Résultats de génération

Après un déclencheur de build, la build se trouve dans l’un des états suivants :

  • en file d’attente : la build se trouve dans une file d’attente en attente de libération des ressources.
  • building : la build est en cours d’exécution.
  • réussite : la build s’est terminée avec succès.
  • failed : la build s’est arrêtée avec des échecs. Vous pouvez résoudre le problème en téléchargeant et en inspectant le journal de build.
  • canceled : la build a été annulée par une action de l’utilisateur ou a expiré.

4.1. Journaux d’activité de génération

Pour une build terminée (réussie ou ayant échoué), téléchargez les journaux pour en savoir plus sur la façon dont la build s’est déroulée. App Center fournit une archive avec les fichiers suivants :

|-- 1_build.txt (this is the general build log)
|-- build (this folder contains a separate log file for each build step)
    |-- <build-step-1>
    |-- <build-step-2>
    |--
    |-- <build-step-n> (e.g. n_Post Job Cleanup.txt)

Les journaux d’activité de l’étape de génération (situés dans le build/ répertoire de l’archive) sont utiles pour comprendre à quelle étape et pourquoi la build a échoué.

4.2. L’application (.apk)

Le .apk fichier est un fichier empaqueté d’application Android qui stocke l’application Android. Si la build a été correctement signée, le .apk fichier peut être installé sur un appareil réel et déployé sur le Play Store. Si la build n’a pas été signée, l’application peut s’exécuter sur un émulateur ou être utilisée à d’autres fins.

Versions et exigences prises en charge

App Center prend en charge les projets PCL (Portable Class Library) et .NET Standard . Reportez-vous à Cloud Build Machines pour connaître les versions de .NET Standard.

App Center ne prend pas en charge les composants du magasin de composants Xamarin et nous vous conseillons d’utiliser des packages NuGet chaque fois qu’ils sont disponibles. Si vous utilisez un composant qui ne peut pas être remplacé, contactez-nous. Consultez l’aide et les commentaires.