Préparation d’une application pour la mise en production
Une fois qu’une application a été codée et testée, il est nécessaire de préparer un paquet pour la distribution. La première tâche de préparation de ce paquet consiste à générer l’application pour sa mise en production, ce qui implique principalement de définir quelques attributs d’application.
Effectuez les étapes suivantes pour générer l’application à mettre en production :
Spécifiez l’icône d’application : une icône d’application doit être spécifiée pour chaque application Xamarin.Android. Bien que non nécessaire techniquement, certaines marketplaces, comme Google Play, en exigent une.
Version de l’application : cette étape implique l’initialisation ou la mise à jour des informations de contrôle de version. Ces informations sont importantes pour les futures mises à jour de l’application et permettent aux utilisateurs de savoir quelle version de l’application est 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 de ProGuard sur le bytecode Java.
Protéger l’application : empêchez les utilisateurs ou les attaquants de déboguer, de falsifier ou de rétroconcevoir l’application en désactivant le débogage, en obscurcissant le code managé, en ajoutant un anti-débogage et un 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 divise si nécessaire le paquet en modules. En outre, vous pouvez fournir à vos utilisateurs un ensemble d’applications Android optimisé pour leurs appareils.
Compiler : cette étape compile le code et les ressources pour vérifier qu’il est généré en mode Release.
Archiver pour la publication : cette étape génère l’application et la place dans une archive à des fins de signature et de publication.
Chacune de ces étapes est décrite ci-dessous plus en détail.
Spécifier l’icône de l'application
Il est vivement 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 qui n’en aurait pas. La propriété Icon de l’attribut Application est utilisée pour spécifier l’icône d’application d’un projet Xamarin.Android.
Dans Visual Studio 2017 et ultérieur, spécifiez l’icône de l’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 qui se trouve dans Resources/drawable/icon.png (notez que l’extension .png n’est pas incluse dans le nom de ressource). Cet attribut peut être également 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é au niveau de la partie supérieure de AssemblyInfo.cs (l’espace de noms de l’attribut Application est Android.App) ; toutefois, vous devrez peut-être ajouter cette instruction using si elle n’est pas déjà présente.
Définir la version de l'application
La gestion de versions est un élément important de la maintenance et de la distribution des applications Android. Sans gestion de versions, il est difficile de déterminer si une application doit être mise à jour ou comment elle doit l’être. Pour faciliter la gestion de versions, Android reconnaît deux types différents d’informations :
Numéro de version : valeur entière (utilisée en interne par Android et l’application) qui représente la version de l’application. Cette valeur est initialement définie sur 1 dans la plupart des applications et elle est ensuite incrémentée avec chaque nouvelle build. Elle n’a aucun lien avec l’attribut de nom de version (voir plus bas). Les applications et les services de publication ne doivent pas montrer cette valeur aux utilisateurs. Cette valeur est stockée dans le fichier AndroidManifest.xml sous la forme
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 la version peut être toute valeur de chaîne qui permet à un utilisateur d’identifier la build qui est installée sur son appareil. Cette valeur est stockée dans le fichier AndroidManifest.xml sous la forme
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
La taille des APK Xamarin.Android peut être réduite par une combinaison de l’éditeur de liens Xamarin.Android, qui supprime le code managé inutile, et l’outil ProGuard du kit Android SDK, qui supprime le bytecode Java non utilisé. Le processus de génération commence par utiliser l’éditeur de liens Xamarin.Android pour optimiser l’application au niveau du code managé (C#), puis il utilise ProGuard (s’il est activé) pour optimiser l’APK au niveau du bytecode Java.
Configurer l'éditeur de liens
Le mode Mise en production désactive le runtime partagé et active la liaison afin que l’application ne fournisse que les parties de Xamarin.Android requises lors de l’exécution. L’éditeur de liens dans Xamarin.Android utilise l’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 considérable de la taille du paquet. Prenons l’exemple d’HelloWorld dont la taille finale de l’APK est réduite de 83 % :
Configuration : Aucune : taille Xamarin.Android 4.2.5 = 17,4 Mo.
Configuration : Assemblys sdk uniquement – Taille Xamarin.Android 4.2.5 = 3,0 Mo.
Définissez les options de l’éditeur de liens via la section Options Android des Propriétés du projet :
Le menu déroulant Édition des liens propose les options suivantes pour contrôler l’éditeur de liens :
Aucun : désactive l’éditeur de liens ; aucune liaison n’est effectuée.
Assemblys sdk uniquement : cette opération lie uniquement les assemblys requis par Xamarin.Android. Les autres assemblys ne seront pas liés.
Sdk et assemblys utilisateur : cette opération lie tous les assemblys requis par l’application, et pas seulement ceux requis par Xamarin.Android.
La liaison peut avoir des effets secondaires inattendus. Il est donc important de tester à nouveau une application en mode Mise en production sur un appareil physique.
ProGuard
ProGuard est un outil du kit Android SDK qui lie et obfusque le code Java. ProGuard est généralement utilisé pour créer des applications plus petites en réduisant l’encombrement des grandes bibliothèques (comme Services Google Play) qui se trouvent dans votre APK. ProGuard supprime le bytecode Java non utilisé, ce qui réduit la taille de l’application. Par exemple, l’utilisation de ProGuard sur de petites applications Xamarin.Android permet généralement une réduction de taille d’environ 24 % : l’utilisation de ProGuard sur des applications plus volumineuses avec plusieurs dépendances de bibliothèques permet 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 le code managé, tandis que ProGuard lie le bytecode Java. Le processus de génération commence par utiliser l’éditeur de liens Xamarin.Android pour optimiser le code managé (C#) de l’application, puis il utilise ProGuard (s’il est activé) pour optimiser l’APK au niveau du bytecode Java.
Si Activer ProGuard est activé, Xamarin.Android exécute l’outil ProGuard sur l’APK qui en résulte. Un fichier de configuration ProGuard est généré et utilisé par ProGuard au moment de la génération. 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 comme 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 en mode Mise en production. Toutes les actions de génération ProGuard sont ignorées sauf si Activer ProGuard est activé. La configuration ProGuard de Xamarin.Android 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 Protection des applications avec Dotfuscator.
Pour plus d’informations sur l’utilisation de l’outil ProGuard, consultez ProGuard.
Protéger l'application
Désactiver le débogage
Au cours du développement d’une application Android, le débogage est réalisé à l’aide du protocole JDWP (Java Debug Wire Protocol). Il s’agit d’une technologie qui permet à des outils tels qu’adb de communiquer avec une machine virtuelle Java pour le débogage. JDWP est activé par défaut pour les builds Debug d’une application Xamarin.Android. JDWP est important pendant le développement, mais peut poser un problème de sécurité pour les applications mises en production.
Important
Désactivez toujours l’état de débogage dans une application mise en production. À défaut, il sera possible (avec JDWP) d’obtenir un accès total au processus Java et d’exécuter du code arbitraire dans le contexte de l’application.
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. Pour ce faire, le 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 (comme Internet et ReadExternalStorage). Toutefois, les builds Debug n’utilisent que les autorisations que vous configurez explicitement. Si vous découvrez qu’en basculant vers la build de mise en production votre application perd une autorisation qui était disponible dans la build Debug, vérifiez que vous avez explicitement activé cette autorisation dans la liste Autorisations nécessaires, comme décrit dans Autorisations.
Protection des applications avec Dotfuscator
Même lorsque le débogage est désactivé, les pirates peuvent repackager une application, en ajoutant ou supprimant des options de configuration ou des autorisations. Ils peuvent alors rétroconcevoir, déboguer ou falsifier l’application. Dotfuscator Community Edition (CE) peut être utilisé pour obfusquer le code managé et injecter du code de détection de l’état de sécurité à l’exécution dans une application Xamarin.Android au moment de la génération pour détecter et répondre si l’application s’exécute sur un appareil rooté.
Dotfuscator CE est fourni avec Visual Studio 2017. Pour utiliser Dotfuscator, cliquez sur Outils > Protection préventive - Dotfuscator.
Pour configurer Dotfuscator CE, consultez Utilisation de Dotfuscator Community Edition avec Xamarin. Une fois configuré, Dotfuscator CE protégera automatiquement chaque build créée.
Regrouper les 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 de compresser les assemblys, ce qui permet de réduire .apk les fichiers. La compression de l’assembly confère également une forme minimale d’obfuscation; cette obfuscation ne doit pas être invoquée.
Cette option requiert une licence Entreprise et est disponible uniquement lorsque l’option Utiliser Fast Deployment est désactivée. Regrouper les assemblys dans le code natif est désactivé par défaut.
Notez que l’option Regrouper les assemblys dans le code natif 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 dans du code natif.
Compilation AOT
L’option Compilation AOT (sur la page Propriétés de création de package) active la compilation Ahead-of-Time (AOT) des assemblys. Lorsque cette option est activée, la charge de démarrage JIT (Just-In-Time) est réduite en précompilant les assemblys avant l’exécution. Le code natif qui en résulte est dans l’APK avec les assemblys non compilés. Cela réduit le temps de démarrage de l’application, mais au détriment de la taille de l’APK qui est légèrement plus grande.
L’option Compilation AOT requiert une licence Entreprise ou supérieure. Compilation AOT est disponible uniquement lorsque le projet est configuré pour le mode Mise en production et elle est désactivée par défaut. Pour plus d’informations sur la compilation AOT, consultez AOT.
Compilateur d'optimisation LLVM
Le compilateur d’optimisation LLVM crée du code compilé plus petit et plus rapide et convertit en code natif les assembys compilés en AOT, mais au détriment de la vitesse de génération qui est plus lente. Le compilateur LLVM est désactivé par défaut. Pour utiliser le compilateur LLVM, l’option Compilation AOT doit d’abord être activée (dans la page Propriétés de l’empaquetage ).
Notes
L’option Compilateur d’optimisation LLVM requiert une licence Entreprise.
Définir les propriétés de création de package
Les propriétés de création de package peuvent être définies dans la section Options Android des Propriétés du projet, comme illustré dans la capture d’écran suivante :
Nombre de ces propriétés, comme Utiliser le runtime partagé et Utiliser Fast Deployment, sont prévues pour le mode Debug. Toutefois, lorsque l’application est configurée pour le mode Mise en production, d’autres paramètres permettent de déterminer la manière dont l’application est optimisée en termes de taille et de vitesse d’exécution, la manière dont elle est protégée contre la falsification et la manière dont elle peut être ajoutée à un package 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 sa mise en production, il est nécessaire de spécifier les architectures de processeur qui sont prises en charge. Un même APK peut contenir du code machine permettant la prise en charge de plusieurs architectures différentes. Pour plus d’informations sur la prise en charge de plusieurs architectures de processeur, consultez Architectures de processeur.
Générer un package (.APK) par ABI sélectionnée
Lorsque cette option est activée, un APK est créé pour chacune des ABI prises en charge (sélectionnées sous l’onglet Avancé, comme décrit dans Architectures de processeur), plutôt qu’un seul grand APK pour toutes les ABI prises en charge. Cette option est disponible uniquement quand le projet est configuré pour le mode Mise en production et elle est désactivée par défaut.
Multi-Dex
Lorsque l’option Activer Multi-Dex est activée, les outils du kit Android SDK sont utilisés pour contourner la limite de 65 000 méthodes du format de fichier .dex. La limitation de méthode de 65 000 est basée sur le nombre de méthodes Java référencées par une application (y compris celles des 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 ne définit que quelques méthodes alors qu’elle en utilise beaucoup (ou de grandes bibliothèques), la limite de 65 000 peut être dépassée.
Il est possible qu’une application n’utilise pas toutes les méthodes de toutes les bibliothèques référencées, et donc qu’un outil tel que ProGuard (voir ci-dessus) puisse supprimer du code les méthodes non utilisées. La bonne pratique consiste à activer Activer Multi-Dex seulement si cela est absolument nécessaire, autrement dit si l’application référence toujours plus de 65 000 méthodes Java même après avoir utilisé ProGuard.
Pour plus d’informations sur Multi-Dex, consultez Configurer les applications avec plus de 64K 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. Une fois que vous avez téléchargé votre offre groupée d’applications signées, Google Play dispose de tout ce dont il a besoin pour créer et signer les API de votre application et les servir à vos utilisateurs à l’aide de la livraison dynamique.
Pour activer la prise en charge des offres groupées d’applications Android, vous devez accepter la valeur de la bundle propriété Android Package Format dans les options de votre projet Android. Avant de procéder, veillez à modifier votre projet en une Release configuration, car les offres groupées d’applications sont destinées uniquement aux packages de mise en production.
Vous pouvez maintenant générer une offre groupée d’applications en suivant le flux d’archivage. Cela génère un bundle d’application pour votre application.
Pour plus d’informations sur les offres groupées d’applications Android, consultez Offres groupées d’applications Android.
Compiler
Une fois toutes les étapes ci-dessus terminées, l’application est prête à être compilée. Sélectionnez Build Rebuild Solution (Reconstruire > la solution ) pour vérifier qu’elle est correctement générée en mode Mise en production. Notez que cette étape ne produit pas encore un APK.
La création de package et la signature sont abordées plus en détail dans la section Signature du paquet d’application.
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 Archiver... :
Archiver... lance le Gestionnaire d’archives et commence le processus d’archivage du bundle d’applications, comme illustré dans cette capture d’écran :
Vous pouvez également créer une archive en cliquant avec le bouton droit sur la solution dans l’Explorateur de solutions, puis en sélectionnant Archiver tout... , ce qui génère la solution et archive tous les projets Xamarin pouvant générer une archive :
Archiver et Archiver tout lancent automatiquement le Gestionnaire d’archives. Pour lancer le Gestionnaire d’archives directement, cliquez sur l’élément de menu Outils > Gestionnaire d’archive... :
Les archives de la solution sont accessibles à tout moment en cliquant avec le bouton droit sur le nœud Solution et en sélectionnant Afficher les archives :
Gestionnaire d'archives
Le Gestionnaire d’archives est composé d’un volet Liste des solutions, d’un volet Liste des archives et d’un Panneau des détails :
Le volet Liste des solutions affiche toutes les solutions ayant au moins un projet archivé. Liste des solutions comprend les sections suivantes :
- Solution actuelle : affiche la solution actuelle. Notez que cette zone peut être vide s’il n’existe aucune archive pour la solution actuelle.
- Toutes les archives : affiche toutes les solutions qui ont une archive.
- Zone de texte rechercher (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.
Le volet Liste des archives affiche la liste de toutes les archives de la solution sélectionnée. 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 le volet Liste des archives font référence à la 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. Cette liste peut également afficher des informations supplémentaires telles que la progression de l’archivage ou de la publication d’un élément.
Le Panneau des 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.
Distribution
Lorsqu’une version archivée de l’application est prête à être publiée, sélectionnez l’archive dans le Gestionnaire d’archives et cliquez sur le bouton Distribuer... :
La boîte de dialogue Canal de distribution affiche des informations sur l’application, indique la progression du workflow de distribution et propose un choix de canaux de distribution. Lors de sa première exécution, deux choix sont présentés :
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 des appareils Android. Poursuivez avec Signature du paquet 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 de test.
Google Play : publie un APK signé sur Google Play. Poursuivez avec Publication sur Google Play pour apprendre comment signer et publier un APK sur Google Play Store.
