Remarque
L’accès à cette page requiert une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page requiert une autorisation. Vous pouvez essayer de modifier des répertoires.
Une fois qu’une application a été codée et testée, il est nécessaire de préparer un package pour la distribution. La première tâche de préparation de ce package consiste à générer l’application pour la version, ce qui implique principalement de définir certains attributs d’application.
Procédez comme suit pour générer l’application à des fins de mise en production :
Spécifier l’icône d’application : chaque application Xamarin.Android doit avoir une icône d’application spécifiée. Bien qu’il ne soit pas techniquement nécessaire, certains marchés, tels que Google Play, l’exigent.
Version de l’application : cette étape implique l’initialisation ou la mise à jour des informations de contrôle de version. Cela est important pour les futures mises à jour de l’application et pour s’assurer que les utilisateurs sont conscients de la version de l’application qu’ils ont installée.
Réduire l’APK : la taille de l’APK final peut être considérablement réduite à l’aide de l’éditeur de liens Xamarin.Android sur le code managé et ProGuard sur le bytecode Java.
Protégez l’application : empêchez les utilisateurs ou les attaquants de déboguer, de falsifier ou d’inverser l’ingénierie de l’application en désactivant le débogage, en obfusquant le code managé, en ajoutant des anti-débogage et anti-falsification et en utilisant la compilation native.
Définir les propriétés d’empaquetage : les propriétés d’empaquetage contrôlent la création du package d’application Android (APK). Cette étape optimise l’APK, protège ses ressources et modularise l’empaquetage en fonction des besoins. En outre, vous pouvez fournir à vos utilisateurs un bundle d’applications Android optimisé pour leurs appareils.
Compiler : cette étape compile le code et les ressources pour vérifier que l’application est générée en mode Mise en production.
Archiver pour publication : cette étape génère l’application et la place dans une archive en vue de sa signature et de sa publication.
Chacune de ces étapes est décrite ci-dessous plus en détail.
Spécifier l’icône d’application
Il est fortement recommandé que chaque application Xamarin.Android spécifie une icône d’application. Certaines places de marché d’applications n’autorisent pas la publication d’une application Android sans une application. La Icon propriété de l’attribut Application est utilisée pour spécifier l’icône d’application pour un projet Xamarin.Android.
Dans Visual Studio 2017 et versions ultérieures, spécifiez l’icône d’application via la section Manifeste Android des propriétés du projet, comme illustré dans la capture d’écran suivante :
Dans ces exemples, @drawable/icon fait référence à un fichier d’icône situé dans Resources/drawable/icon.png (notez que l’extension .png n’est pas incluse dans le nom de la ressource). Cet attribut peut également être déclaré dans le fichier Properties\AssemblyInfo.cs, comme illustré dans cet exemple d’extrait de code :
[assembly: Application(Icon = "@drawable/icon")]
Normalement, using Android.App est déclaré en haut de AssemblyInfo.cs (l’espace de noms de l’attribut Application est Android.App) ; toutefois, vous devrez peut-être ajouter cette using instruction si elle n’est pas déjà présente.
Version de l’application
Le contrôle de version est important pour la maintenance et la distribution des applications Android. Sans un certain type de contrôle de version en place, il est difficile de déterminer si ou comment une application doit être mise à jour. Pour faciliter le contrôle de version, Android reconnaît deux types d’informations différents :
Numéro de version : valeur entière (utilisée en interne par Android et l’application) qui représente la version de l’application. La plupart des applications commencent par cette valeur définie sur 1, puis elles sont incrémentées avec chaque build. Cette valeur n’a aucune relation ni affinité avec l’attribut de nom de version (voir ci-dessous). Les applications et les services de publication ne doivent pas afficher cette valeur aux utilisateurs. Cette valeur est stockée dans le fichier AndroidManifest.xml en tant que
android:versionCode.Nom de la version : chaîne utilisée uniquement pour communiquer des informations à l’utilisateur sur la version de l’application (telle qu’installée sur un appareil spécifique). Le nom de la version est destiné à être affiché aux utilisateurs ou dans Google Play. Cette chaîne n’est pas utilisée en interne par Android. Le nom de version peut être n’importe quelle valeur de chaîne qui aiderait un utilisateur à identifier la build installée sur son appareil. Cette valeur est stockée dans le fichier AndroidManifest.xml en tant que
android:versionName.
Dans Visual Studio, ces valeurs peuvent être définies dans la section Manifeste Android des propriétés du projet, comme illustré dans la capture d’écran suivante :
Réduire l’APK
Les APKs Xamarin.Android peuvent être réduits par le biais d’une combinaison de l’éditeur de liens Xamarin.Android, qui supprime le code managé inutile, et de l’outil ProGuard du Kit de développement logiciel (SDK) Android, qui supprime le bytecode Java inutilisé. Le processus de génération utilise d’abord l’éditeur de liens Xamarin.Android pour optimiser l’application au niveau du code managé (C#), puis il utilise ensuite ProGuard (si activé) pour optimiser l’APK au niveau du bytecode Java.
Configurer l'éditeur de liens
Le mode de mise en production désactive le runtime partagé et active la liaison afin que l’application ne fournit que les éléments de Xamarin.Android requis lors de l’exécution. L’éditeur de liens dans Xamarin.Android utilise une analyse statique pour déterminer quels assemblys, types et membres de type sont utilisés ou référencés par une application Xamarin.Android. L’éditeur de liens ignore ensuite tous les assemblys, types et membres qui ne sont pas utilisés (ou référencés). Cela peut entraîner une réduction significative de la taille du package. Prenons l’exemple d’HelloWorld dont la taille finale de l’APK est réduite de 83 % :
Configuration : Aucun – Xamarin.Android 4.2.5 Taille = 17,4 Mo.
Configuration : Assemblages SDK uniquement – Xamarin.Android 4.2.5 Taille = 3,0 Mo.
Définissez les options de l’éditeur de liens via la section Options Android du projet Propriétés :
Le menu déroulant Liaison fournit les options suivantes pour contrôler l’éditeur de liens :
Aucun : cela désactive l’éditeur de liens ; aucune liaison n’est effectuée.
Assemblys du Kit de développement logiciel (SDK) uniquement : cela liera uniquement les assemblys requis par Xamarin.Android. Les autres assemblées ne seront pas liées.
Assemblys de SDK et assemblys d’utilisateur : avec cette option, tous les assemblys qui sont requis par l’application seront liés, pas seulement ceux qui sont requis par Xamarin.Android.
La liaison peut produire des effets secondaires inattendus. Il est donc important qu’une application soit retestée en mode Mise en production sur un appareil physique.
ProGuard
ProGuard est un outil Android SDK qui lie et obfusque le code Java. ProGuard est normalement utilisé pour créer des applications plus petites en réduisant l’empreinte des bibliothèques incluses volumineuses (telles que Google Play Services) dans votre APK. ProGuard supprime le bytecode Java inutilisé, ce qui réduit la taille de l’application résultante. Par exemple, l’utilisation de ProGuard sur de petites applications Xamarin.Android atteint généralement environ 24% réduction de la taille : l’utilisation de ProGuard sur des applications plus volumineuses avec plusieurs dépendances de bibliothèque obtient généralement une réduction de taille encore plus grande.
ProGuard n’est pas une alternative à l’éditeur de liens Xamarin.Android. L’éditeur de liens Xamarin.Android lie du code géré, tandis que ProGuard lie le bytecode Java. Le processus de génération utilise d’abord l’éditeur de liens Xamarin.Android pour optimiser le code managé (C#) dans l’application, puis il utilise ensuite ProGuard (si activé) pour optimiser l’APK au niveau du bytecode Java.
Lorsque l’option Activer ProGuard est activée, Xamarin.Android exécute l’outil ProGuard sur l’APK résultant. Un fichier de configuration ProGuard est généré et utilisé par ProGuard au moment de la compilation. Xamarin.Android prend également en charge les actions de génération ProguardConfiguration personnalisées. Vous pouvez ajouter un fichier de configuration ProGuard personnalisé à votre projet, cliquer dessus avec le bouton droit et le sélectionner en tant qu’action de génération, comme illustré dans cet exemple :
ProGuard est désactivé par défaut. L’option Activer ProGuard est disponible uniquement lorsque le projet est défini sur le mode Release. Toutes les actions de génération ProGuard sont ignorées, sauf si l’option Activer ProGuard est cochée. La configuration Xamarin.Android ProGuard n’obfusque pas l’APK et il n’est pas possible d’activer l’obfuscation, même avec des fichiers de configuration personnalisés. Si vous souhaitez utiliser l’obfuscation, consultez Application Protection avec Dotfuscator.
Pour plus d’informations sur l’utilisation de l’outil ProGuard, consultez ProGuard.
Protéger l’application
Désactiver le débogage
Pendant le développement d’une application Android, le débogage est effectué avec l’utilisation du protocole JDWP ( Java Debug Wire Protocol ). Il s’agit d’une technologie qui permet aux outils tels qu’adb de communiquer avec une machine virtuelle JVM à des fins de débogage. JDWP est activé par défaut pour les builds Debug d’une application Xamarin.Android. Bien que JDWP soit important pendant le développement, il peut poser un problème de sécurité pour les applications publiées.
Importante
Désactivez toujours l’état de débogage dans une application publiée, car il est possible (via JDWP) d’obtenir un accès complet au processus Java et d’exécuter du code arbitraire dans le contexte de l’application si cet état de débogage n’est pas désactivé.
Le manifeste Android contient l’attribut android:debuggable , qui contrôle si l’application peut ou non être déboguée. Il est considéré comme une bonne pratique de définir l’attribut android:debuggable sur false. La méthode la plus simple consiste à ajouter une instruction de compilation conditionnelle dans AssemblyInfo.cs :
#if DEBUG
[assembly: Application(Debuggable=true)]
#else
[assembly: Application(Debuggable=false)]
#endif
Notez que les builds Debug définissent automatiquement certaines autorisations pour faciliter le débogage (par exemple , Internet et ReadExternalStorage). Toutefois, les builds release utilisent uniquement les autorisations que vous configurez explicitement. Si vous constatez que le passage à la build Release entraîne la perte d’une autorisation disponible dans la build Debug, vérifiez que vous avez explicitement activé cette autorisation dans la liste des autorisations requises , comme décrit dans Autorisations.
Protection des applications avec Dotfuscator
Même avec le débogage désactivé, il est toujours possible pour les attaquants de re-empaqueter une application, d’ajouter ou de supprimer des options de configuration ou des autorisations. Cela leur permet de rétroconcevoir, de déboguer ou de falsifier l’application. Dotfuscator Community Edition (CE) peut être utilisé pour obfusquer le code managé et injecter le code de détection de l'état de sécurité à l'exécution dans une application Xamarin.Android lors de la compilation pour détecter et réagir si l'application s'exécute sur un appareil rooté.
Dotfuscator CE est inclus dans Visual Studio 2017. Pour utiliser Dotfuscator, cliquez sur Tools > PreEmptive Protection - Dotfuscator.
Pour configurer Dotfuscator CE, consultez Utilisation de Dotfuscator Community Edition avec Xamarin. Une fois qu’il est configuré, Dotfuscator CE protège automatiquement chaque build créée.
Regrouper des assemblys dans du code natif
Lorsque cette option est activée, les assemblys sont regroupés dans une bibliothèque partagée native. Cela permet aux assemblies d’être compressées, ce qui permet d'obtenir des fichiers plus petits .apk. La compression d'assemblage confère également une forme minimale d'obfuscation. Cette obfuscation ne doit pas être considérée fiable.
Cette option nécessite une licence Entreprise et n’est disponible que lorsque l’utilisation du déploiement rapide est désactivée. Les assemblys groupés dans du code natif sont désactivés par défaut.
Notez que l’option Bundle into Native Code ne signifie pas que les assemblys sont compilés en code natif. Il n’est pas possible d’utiliser la compilation AOT pour compiler des assemblys en code natif.
Compilation AOT
L’option Compilation AOT (dans la page Propriétés d’empaquetage) active la compilation AOT (Ahead-of-Time) des assemblies. Lorsque cette option est activée, la surcharge de démarrage juste-à-temps (JIT) est réduite en précompilant les assemblys avant l’exécution. Le code natif résultant est inclus dans l’APK, ainsi que les assemblys noncompilés. Cela entraîne une durée de démarrage d’application plus courte, mais au détriment de tailles APK légèrement plus grandes.
L’option de compilation AOT nécessite une licence Entreprise ou une licence supérieure. La compilation AOT est disponible uniquement lorsque le projet est configuré pour le mode Mise en production et qu’il est désactivé par défaut. Pour plus d’informations sur la compilation AOT, consultez AOT.
LLVM Optimisation du compilateur
Le compilateur d’optimisation LLVM crée du code compilé plus petit et plus rapide et convertit les assemblys compilés par AOT en code natif, mais au détriment des temps de génération plus lents. Le compilateur LLVM est désactivé par défaut. Pour utiliser le compilateur LLVM, l’option de compilation AOT doit d’abord être activée (dans la page Propriétés de l’empaquetage ).
Remarque
L’option LLVMOptiming Compiler nécessite une licence Entreprise.
Définir les propriétés d’empaquetage
Les propriétés d’empaquetage peuvent être définies dans la section Options Android des propriétés du projet, comme illustré dans la capture d’écran suivante :
La plupart de ces propriétés, telles que l’utilisation du runtime partagé et l’utilisation du déploiement rapide , sont destinées au mode débogage. Toutefois, lorsque l’application est configurée pour le mode Mise en production, il existe d’autres paramètres qui déterminent comment l’application est optimisée pour la taille et la vitesse d’exécution, la façon dont elle est protégée contre la falsification et la façon dont elle peut être empaquetée pour prendre en charge différentes architectures et restrictions de taille.
Spécifier les architectures prises en charge
Lors de la préparation d’une application Xamarin.Android pour la mise en production, il est nécessaire de spécifier les architectures de processeur prises en charge. Un seul APK peut contenir du code machine pour prendre en charge plusieurs architectures différentes. Pour plus d’informations sur la prise en charge de plusieurs architectures CPU, consultez Architectures CPU.
Générer un package (. APK) par ABI sélectionné
Lorsque cette option est activée, un APK est créé pour chacun des ABI pris en charge (sélectionnés sous l’onglet Avancé , comme décrit dans Architectures du processeur) plutôt qu’un seul APK volumineux pour tous les fichiers ABI pris en charge. Cette option est disponible uniquement lorsque le projet est configuré pour le mode Mise en production et qu’il est désactivé par défaut.
Multi-Dex
Lorsque l’option Activer Multi-Dex est activée, les outils Android SDK sont utilisés pour contourner la limite de 65K méthodes du format de fichier .dex. La limitation de méthode 65K est basée sur le nombre de méthodes Java référencées par une application (y compris dans les bibliothèques dont dépend l’application) : elle n’est pas basée sur le nombre de méthodes écrites dans le code source. Si une application définit uniquement quelques méthodes mais utilise de nombreuses (ou grandes bibliothèques), il est possible que la limite de 65 Ko soit dépassée.
Il est possible qu’une application n’utilise pas chaque méthode dans chaque bibliothèque référencée ; Par conséquent, il est possible qu’un outil tel que ProGuard (voir ci-dessus) puisse supprimer les méthodes inutilisées du code. La meilleure pratique consiste à activer Activer Multi-Dex uniquement si nécessaire, c’est-à-dire que l’application fait toujours référence à plus de 65 000 méthodes Java même après l’utilisation de ProGuard.
Pour plus d’informations sur Multi-Dex, consultez Configurer des applications avec plus de 64 000 méthodes.
Offres groupées d’applications Android
Les offres groupées d’applications diffèrent des API, car elles ne peuvent pas être déployées directement sur un appareil. Il s’agit plutôt d’un format destiné à être chargé avec l’ensemble de votre code compilé et de vos ressources. Après avoir téléchargé votre bundle d'applications signé, Google Play aura tout ce dont il a besoin pour générer et signer les APK de votre application et les servir à vos utilisateurs à l’aide de Dynamic Delivery.
Pour activer la prise en charge des offres groupées d’applications Android, vous devez choisir la valeur de la bundle propriété Android Package Format dans les options de votre projet Android. Avant de faire cela, assurez-vous de modifier votre projet pour le configurer en Release, car les bundles d'applications sont réservés uniquement aux packages de mise en production.
Vous pouvez maintenant générer un ensemble d’applications en suivant le flux d’archivage. Cela génère un ensemble d’applications pour votre application.
Pour plus d’informations sur les offres groupées d’applications Android, consultez Bundles d’applications Android.
Compiler
Une fois toutes les étapes ci-dessus terminées, l’application est prête à être compilée. Sélectionnez Générer > Regénérer la solution pour vérifier que l’application est correctement générée en mode Mise en production. Notez que cette étape ne produit pas encore d’APK.
La signature du package d’application traite plus en détail de l’empaquetage et de la signature.
Archiver pour publication
Pour commencer le processus de publication, cliquez avec le bouton droit sur le projet dans l’Explorateur de solutions , puis sélectionnez l’élément de menu contextuel Archive... :
Archiver... lance le Gestionnaire d’archivage et commence le processus d’archivage du bundle d’applications, comme illustré dans cette capture d’écran :
Une autre façon de créer une archive consiste à cliquer avec le bouton droit sur la solution dans l’Explorateur de solutions et à sélectionner Archiver tout..., qui génère la solution et archive tous les projets Xamarin qui peuvent générer une archive :
Archiver et archiver tout lance automatiquement le Gestionnaire d’archivage. Pour lancer directement le Gestionnaire d’archive, cliquez sur l’élément de > menu Outils Archive Manager... :
Les archives de la solution à tout moment en cliquant avec le bouton droit sur le nœud Solution et en sélectionnant Afficher les archives :
Gestionnaire d’archivage
Le Gestionnaire d’archives est composé d’un volet Liste de solutions , d’une liste d’archives et d’un panneau Détails :
La liste des solutions affiche toutes les solutions ayant au moins un projet archivé. La liste des solutions comprend les sections suivantes :
- Solution actuelle : affiche la solution actuelle. Notez que cette zone peut être vide si la solution actuelle n’a pas d’archive existante.
- Toutes les archives : affiche toutes les solutions qui ont une archive.
- Zone de texte de recherche (en haut) : filtre les solutions répertoriées dans la liste Toutes les archives en fonction de la chaîne de recherche entrée dans la zone de texte.
La liste des archives affiche la liste de toutes les archives pour la solution sélectionnée. La liste des archives comprend les sections suivantes :
- Nom de la solution sélectionnée : affiche le nom de la solution sélectionnée dans la liste des solutions. Toutes les informations affichées dans la liste des archives font référence à cette solution sélectionnée.
- Filtre de plateformes : ce champ permet de filtrer les archives par type de plateforme (par exemple, iOS ou Android).
- Éléments d’archivage : liste des archives pour la solution sélectionnée. Chaque élément de cette liste inclut le nom du projet, la date de création et la plateforme. Il peut également afficher des informations supplémentaires telles que la progression lorsqu’un élément est archivé ou publié.
Le panneau Détails affiche des informations supplémentaires sur chaque archive. Il permet également à l’utilisateur de démarrer le workflow de distribution ou d’ouvrir le dossier dans lequel la distribution a été créée. La section Commentaires de build permet d’inclure des commentaires de build dans l’archive.
Répartition
Lorsqu’une version archivée de l’application est prête à être publiée, sélectionnez l’archive dans le Gestionnaire d’archivage, puis cliquez sur le bouton Distribuer... :
La boîte de dialogue Canal de distribution affiche des informations sur l’application, une indication de la progression du flux de travail de distribution et un choix de canaux de distribution. Lors du premier démarrage, deux options sont proposées :
Il est possible de choisir l’un des canaux de distribution suivants :
Ad Hoc : enregistre un APK signé sur le disque qui peut être chargé de manière indépendante sur les appareils Android. Continuez à signer le package d’application pour apprendre à créer une identité de signature Android, à créer un certificat de signature pour les applications Android et à publier une version ad hoc de l’application sur disque. Il s’agit d’un bon moyen de créer un APK à des fins de test.
Google Play : publie un APK signé sur Google Play. Continuez à publier sur Google Play pour apprendre à signer et publier un APK dans le Google Play Store.
