Partager via

Création d’applications Java pour Android

  • Article

Important

Visual Studio App Center doit être mis 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 vers lesquelles vous pouvez envisager de migrer.

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

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

  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, la build doit être signée avec un certificat valide.

Notes

App Center effectue le suivi du projet en effectuant une recherche dans les fichiers de répertoire gradle (et gradlew) du projet Android. N’incluez pas ces fichiers dans le projet .gitignore, car App Center Build 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. Comme solution de contournement, toutes les instances de jcenter() peuvent être supprimées du build.gradle fichier et remplacées par jcenter { url "http://jcenter.bintray.com/"}. Pour en savoir plus sur l’arrêt de JCenter , cliquez ici.

1. Liaison de votre dépôt

Si ce n’est déjà fait, vous devez vous connecter à votre compte de service de dépôt. Une fois votre compte connecté, sélectionnez le dépôt où se trouve votre projet Android. Pour configurer une build pour un dépôt, vous avez besoin d’une autorisation d’administrateur et d’extraction pour celui-ci.

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, 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. Déclencheurs de génération

Par défaut, une nouvelle build est déclenchée chaque fois qu’un développeur envoie un push à une branche configurée. C’est ce qu’on appelle « Intégration continue ». Si vous préférez déclencher une nouvelle génération 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 (au niveau de l’application). Sélectionnez la variante de build à générer.

Notes

App Center Build prend en charge la recherche de variantes de build en tant que combinaison d’un type de build (débogage, version ou défini sur mesure) et d’une de vos variantes 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 une offre groupée d’applications Android (.aab)

L’offre groupée d’applications Android est un format de distribution qui est chargé sur le Play Store et utilisé pour générer des API optimisées pour des appareils spécifiques. Pour en savoir plus sur l’offre groupée d’applications Android, consultez la documentation android officielle.

Activez l’option pour Android App Bundle pour produire un .aab en plus du .apk. Si le build.gradle fichier (au 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

Lorsque 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 pendant la build réelle et ne sera pas validée dans votre dépôt.

3.5. Signature de code

Une build réussie génère un fichier et un .apk fichier supplémentaire .aab si cette option est activée. 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 produites à partir d’une branche, activez la connexion de code dans le volet de configuration, chargez votre magasin de clés dans votre dépôt et fournissez les informations d’identification appropriées 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 ..apk

3.6. Lancer votre build réussi 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 supplémentaires au temps de génération total. En savoir plus sur la configuration des tests de lancement.

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

Des informations spécifiques sur votre build seront collectées à partir de votre fichier Gradle, y compris 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 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 Distribuer. 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 sur 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 Intune destinations du Store, un standard .apk est utilisé même si un .aab 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.
  • building : l’application crée et exécute des tâches associées.
  • réussi : 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 résoudre les problèmes.
  • annulé : la build a été annulée par l’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 spécifiques à l’étape de build (situés dans le répertoire build/de l’archive) sont utiles pour résoudre les problèmes et comprendre quelle étape et pourquoi la build a échoué.

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 APIK

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

4.4. Fichier de mappage de la désobfuscation (mapping.txt)

Le mapping.txt fichier contient des informations sur la façon de mapper des traces de pile obfuscatées pour l’application aux noms de classes et de méthodes 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 rapports d’incident activé et que vous utilisez Proguard ou R8 pour réduire et masquer le fichier binaire de l’application, le service de rapports d’incidents nécessite ce mapping.txt fichier pour qu’une build affiche des rapports d’incidents lisibles par l’utilisateur (désobfuscatés).
  • Si vous avez déjà intégré un autre KIT de développement logiciel (SDK) à des fins de création de rapports d’incidents dans votre application (par exemple, le Kit de développement logiciel (SDK) HockeyApp), le service correspondant exige que le fichier affiche des mapping.txt 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 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 configurées correctement. Votre dépôt doit inclure un wrapper Gradle.

Voir aussi : Informations sur la machine de génération cloud