Partager via

Création d’applications Java pour Android

  • Article

Important

Visual Studio App Center est prévu pour la mise hors service le 31 mars 2025. Bien que vous puissiez continuer à utiliser Visual Studio App Center jusqu’à ce qu’il soit entièrement mis hors service, il existe plusieurs alternatives recommandées que vous pouvez envisager de migrer vers.

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

Pour créer votre première application Android, procédez comme suit :

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

Remarque

Pour que l’application s’exécute sur un appareil réel, la build doit être signée avec un certificat valide.

Remarque

App Center effectue le suivi du projet en recherchant les fichiers de répertoire gradle (et gradlew) du projet Android. N’incluez pas ces fichiers dans le projet .gitignore, car la build App Center ne pourra pas les trouver.

Avertissement

En raison de l’arrêt récent de JCenter, certaines applications peuvent rencontrer des échecs de tâche Gradle lors de la génération avec App Center. Consultez le guide de migration fourni par Gradle. Pour contourner ce build.gradle problème, toutes les instances du jcenter() fichier peuvent être supprimées et remplacées par jcenter { url "http://jcenter.bintray.com/"}. En savoir plus sur l’arrêt JCenter ici.

1. Liaison de votre référentiel

Vous devez vous connecter à votre compte de service de référentiel si ce n’est pas déjà fait. Une fois votre compte connecté, sélectionnez le référentiel où se trouve votre projet Android. Pour configurer une build pour un référentiel, vous avez besoin d’une autorisation d’administrateur et d’extraction pour celle-ci.

2. Sélection d’une branche

Après avoir sélectionné un référentiel, sélectionnez la branche que vous souhaitez générer. Par défaut, toutes les branches actives sont répertoriées.

3. Configuration de votre première build

Avant votre première build, le projet Android doit être configuré.

3.1. Créer des déclencheurs

Par défaut, une nouvelle build est déclenchée chaque fois qu’un développeur envoie (push) à une branche configurée. C’est ce qu’on appelle « Intégration continue ». Si vous préférez déclencher une nouvelle build manuellement, vous pouvez modifier ce paramètre dans le volet de configuration.

3.2. Variante de build

Les variantes de build disponibles sont renseignées à partir des types de build et des saveurs de produit spécifiés dans le fichier build.gradle (niveau de l’application). Sélectionnez la variante de build à générer.

Remarque

App Center Build prend en charge la recherche de variantes de build comme combinaison d’un type de build (débogage, mise en production ou définition personnalisée) et de l’une de vos versions de produit déclarées gradle. La détection des dimensions de saveur (combinaisons de plusieurs saveurs de produit) n’est pas prise en charge pour l’instant.

3.3. Générer un bundle d’applications Android (.aab)

Android App Bundle est un format de distribution chargé dans le Play Store et utilisé pour générer des API optimisées pour des appareils spécifiques. Vous trouverez plus d’informations sur le bundle d’applications Android dans la documentation Android officielle.

Activez l’option pour Android App Bundle afin de produire un .aab ajout à l’option .apk. Si le build.gradle fichier (niveau de l’application) contient le android.bundle bloc, cette option est déjà activée.

3.4. Incrémenter le numéro de version

Lorsqu’elle est activée, le code de version dans l’AndroidManifest.xml de votre application incrémente automatiquement pour chaque build. La modification se produit pendant la build réelle et ne sera pas validée dans votre référentiel.

3.5. Signature de code

Une build réussie génère un .apk fichier et un fichier supplémentaire .aab s’il est activé. Pour libérer la build dans le Play Store, elle doit être signée avec un certificat valide stocké dans un magasin de clés. Pour signer les builds générées à partir d’une branche, activez la connexion de code dans le volet de configuration, chargez votre magasin de clés dans votre référentiel et fournissez les informations d’identification pertinentes dans le volet de configuration. Vous pouvez en savoir plus sur la connexion de code dans la documentation de signature de code Android d’App Center. Le .aab sera signé à l’aide des mêmes informations d’identification que le .apk.

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

Utilisez votre fichier APK nouvellement produit pour tester si votre application démarre sur un appareil réel. Cela ajoute environ 10 minutes de plus à la durée totale de génération. En savoir plus sur la configuration des tests de lancement.

3.7. Configurer à partir du fichier build.gradle (niveau de l’application)

Des informations spécifiques sur votre build seront collectées à partir de votre fichier Gradle, notamment les dépendances, la version des outils de génération, les types de build et les saveurs de produit.

3.8. Distribuer la build

Vous pouvez configurer chaque build réussie à partir d’une branche pour être 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 de magasin à partir du service Distribuer. Il existe toujours un groupe de distribution par défaut appelé « Collaborateurs » qui inclut tous les utilisateurs qui ont accès à l’application.

Remarque

Si vous distribuez dans google Play Store, un bundle 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 du Magasin Intune, un standard .apk sera utilisé même si un .aab objet est également généré.

4. Générer des résultats

Une fois qu’une build est déclenchée, elle peut se trouver dans les états suivants :

  • mis en file d’attente : la build se trouve dans une file d’attente qui attend que les ressources soient libérées.
  • génération : l’application crée et exécute des tâches associées.
  • réussite : la build est terminée avec succès.
  • échec : la build s’est terminée, mais elle a échoué. Vous pouvez télécharger et inspecter le journal de build pour la résolution des problèmes.
  • annulé : la build a été annulée par l’action de l’utilisateur ou a expiré.

4.1. Journaux 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 a été effectué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 spécifiques à l’étape de génération (situés dans le répertoire/build de l’archive) sont utiles pour la résolution des problèmes et la compréhension de l’étape et de la raison de l’échec de la build.

4.2. Package d’application (APK)

L’APK est un package qui contient l’application Android et les ressources. Si la build est correctement signée, l’APK 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’APK peut être exécuté sur un émulateur ou utilisé à d’autres fins.

4.3. Génération de plusieurs API

Si votre configuration d’application génère plusieurs API, vous devez également créer un APK universel. Notre système de génération fonctionne avec un fichier APK principal et ignore toutes les API spécifiques à une certaine densité d’uc ou d’écran. Pour en savoir plus sur les fractionnements APK et la création d’un APK universel, lisez le guide de fractionnement ABI.

4.4. Fichier de déobfuscation-mappage (mapping.txt)

Le mapping.txt fichier contient des informations sur la façon de mapper les traces de pile obfuscatées de l’application aux noms de classe et de méthode d’origine.

  • Si vous avez précédemment intégré le Kit de développement logiciel (SDK) App Center dans votre application avec le module de création de rapports d’incident activé et utilisez Proguard ou R8 pour réduire et masquer le fichier binaire de l’application, le service de création de rapports d’incident nécessite que ce mapping.txt fichier affiche les rapports d’incident lisibles par l’homme (déobfuscated).
  • Si vous avez précédemment intégré un autre SDK à des fins de création de rapports d’incident dans votre application (par exemple, le Kit de développement logiciel (SDK) HockeyApp), le service correspondant nécessite que le mapping.txt fichier affiche des rapports d’incident lisibles.

5. Versions et exigences prises en charge

La version minimale prise en charge pour créer des applications Android est 7.0 (niveau d’API 24). Les applications Android peuvent avoir un niveau d’API minimal inférieur requis pour s’exécuter, mais doivent cibler au moins le niveau d’API 24.

Les applications doivent être générées avec Gradle et le plug-in Android Gradle pour être correctement configurées. Votre référentiel doit inclure un wrapper Gradle.

Voir aussi : Informations sur la machine de build cloud