Free Press

Android Studio fournit un débogueur qui vous permet de faire ce qui suit et plus encore :

• Sélectionner un appareil pour déboguer votre application.
• Définir des points d’arrêt dans votre code Java, Kotlin et C/C++.
• Examiner les variables et évaluer les expressions au moment de l’exécution.

Cette page comprend des instructions pour les opérations de base du débogueur. Pour plus de documentation, consultez également les docs de débogage d’IntelliJ IDEA.

Activer le débogage

Avant de pouvoir commencer le débogage, vous devez vous préparer comme suit :

• Activer le débogage sur votre périphérique :

  Si vous utilisez l’émulateur, cela est activé par défaut. Mais pour un périphérique connecté, vous devez activer le débogage dans les options du développeur du périphérique.

• Exécuter une variante de construction débuggable:

  Vous devez utiliser une variante de construction qui inclut debuggable true dans la configuration de la construction. Habituellement, vous pouvez simplement sélectionner la variante « debug » par défaut qui est incluse dans chaque projet Android Studio (même si elle n’est pas visible dans le fichier build.gradle). Mais si vous définissez de nouveaux types de build qui devraient être débuggeables, vous devez ajouter `debuggable true` au type de build:

  android { buildTypes { customDebugType { debuggable true ... } }}

  Cette propriété s’applique également aux modules avec du code C/C++. (La propriété jniDebuggable n’est plus utilisée.)

  Si votre application dépend d’un module de bibliothèque que vous souhaitez également déboguer, cette bibliothèque doit également être empaquetée avec debuggable true afin qu’elle conserve ses symboles de débogage.Pour vous assurer que les variantes déboguables de votre projet d’application reçoivent la variante déboguable d’un module de bibliothèque, veillez à publier des versions non par défaut de votre bibliothèque.

Démarrer le débogage

Vous pouvez démarrer une session de débogage comme suit :

1. Définissez quelques points d’arrêt dans le code de l’app.
2. Dans la barre d’outils, sélectionnez un périphérique sur lequel déboguer votre app dans le menu déroulant du périphérique cible.

   

   Si vous n’avez aucun périphérique configuré, alors vous devez soit connecter un périphérique via USB, soit créer un AVD pour utiliser l’émulateur Android.

3. Dans la barre d’outils, cliquez sur Déboguer .

   Si vous voyez une boîte de dialogue vous demandant si vous voulez « passer de Run à Debug », cela signifie que votre application est déjà en cours d’exécution sur l’appareil et qu’elle va redémarrer afin de commencer le débogage. Si vous préférez garder la même instance de l’app en cours d’exécution, cliquez sur Annuler le débogage et attachez plutôt le débogueur à une app en cours d’exécution.

   Sinon, Android Studio construit un APK, le signe avec une clé de débogage, l’installe sur l’appareil sélectionné et l’exécute. Si vous ajoutez du code C et C++ à votre projet, Android Studio exécute également le débogueur LLDB dans la fenêtre Debug pour déboguer votre code natif.

4. Si la fenêtre Debug n’est pas ouverte, sélectionnez View > Tool Windows > Debug (ou cliquez sur Debug dans la barre de la fenêtre d’outils), puis cliquez sur l’onglet Debugger, comme indiqué sur la figure 1.

   Figure 1. La fenêtre du débogueur, montrant le thread actuel et l’arbre d’objets pour une variable

Attacher le débogueur à une app en cours d’exécution

Si votre app est déjà en cours d’exécution sur votre appareil, vous pouvez commencer le débogage sans redémarrer votre app comme suit :

1. Cliquez sur Attacher le débogueur au processus Android .
2. Dans la boîte de dialogue Choisir le processus, sélectionnez le processus auquel vous souhaitez attacher le débogueur.

   Si vous utilisez un émulateur ou un appareil enraciné, vous pouvez cocher Afficher tous les processus pour voir tous les processus.

   Dans le menu déroulant Utiliser les paramètres du débogueur Android à partir de, vous pouvez sélectionner une configuration d’exécution/débogage existante. (Pour le code C et C++, cela vous permet de réutiliser les commandes de démarrage LLDB, les commandes de post-attachement LLDB et les répertoires de symboles dans une configuration existante). Si vous ne disposez pas d’une configuration d’exécution/débogage existante, sélectionnez Créer nouveau. Cette sélection active le menu déroulant Debug Type, dans lequel vous pouvez sélectionner un autre type de débogage. Par défaut, Android Studio utilise le type de débogage Auto pour sélectionner la meilleure option de débogage pour vous, selon que votre projet comprend du code Java ou C/C++.

3. Cliquez sur OK.

   La fenêtre de débogage apparaît.

Remarque : le débogueur et le collecteur de déchets d’Android Studio sont faiblement intégrés. La machine virtuelle Android garantit que tout objet dont le débogueur a connaissance n’est pas garbage collector avant que le débogueur ne se déconnecte. Cela peut entraîner une accumulation d’objets au fil du temps pendant que le débogueur est connecté. Par exemple, si le débogueur voit un thread en cours d’exécution, l’objet Thread associé n’est pas garbage collecté jusqu’à ce que le débogueur se déconnecte, même si le thread a pris fin.

Changer le type de débogueur

Parce que différents outils de débogage sont nécessaires pour déboguer du code Java/Kotlin et du code C/C++, le débogueur d’Android Studio vous permet de sélectionner le type de débogueur à utiliser. Par défaut, Android Studiodécide du débogueur à utiliser en fonction des langues qu’il détecte dans votre projet (avec le type de débogueurAuto). Cependant, vous pouvez sélectionner manuellement le débogueur dans la configuration de débogage (cliquez sur Exécuter > ModifierConfigurations) ou dans la boîte de dialogue qui apparaît lorsque vous cliquez sur Exécuter > Attacher le débogueur au processus Android.

Les types de débogage disponibles incluent les suivants :

Auto Sélectionnez ce type de débogage si vous souhaitez qu’Android Studio choisisse automatiquement la meilleure option pour le code que vous déboguez. Par exemple, si vous avez du code C ou C++ dans votre projet, Android Studio utilise automatiquement le type de débogage Dual. Sinon, Android Studio utilise le type de débogage Java. Java Sélectionnez ce type de débogage si vous souhaitez déboguer uniquement le code écrit en Java ou en Kotlin – le débogueur Java ignore les points d’arrêt ou les surveillances que vous avez définis dans votre code natif. Natif (disponible uniquement pour le code C/C++) Sélectionnez ce type de débogage si vous souhaitez utiliser uniquement LLDB pour déboguer votre code. Lorsque vous utilisez ce type de débogage, la vue de session du débogueur Java n’est pas disponible. Par défaut, LLDB inspecte uniquement votre code natif et ignore les points d’arrêt dans votre code Java. Si vous souhaitez également déboguer votre code Java, vous devez passer au type de débogage Auto ou Dual.

Le débogage natif fonctionne uniquement sur les appareils qui répondent aux exigences suivantes :

• L’appareil prend en charge run-as.

  Pour vérifier si l’appareil prend en charge run-as, exécutez la commande suivante sur le shell ADB qui est connecté à votre appareil :

  run-as your-package-name pwd

  Remplacez your-package-name par le nom du package de votre app. Si le périphérique prend en charge run-as, la commande devrait retourner sans aucune erreur.

• Le périphérique a ptrace activé.

  Pour vérifier si ptrace est activé, exécutez la commande suivante sur le shell ADB qui est connecté à votre périphérique:

  sysctl kernel.yama.ptrace_scope

  Si ptrace est activé, la commande imprimera la valeur 0 ou une erreur unknown key. Si ptrace n’est pas activé, elle imprimera une valeur autre que 0.

Dual (disponible uniquement avec le code C/C++) Sélectionnez ce type de débogage si vous souhaitez basculer entre le débogage du code Java et celui du code natif. Android Studio attache à la fois le débogueur Java et LLDB au processus de votre application, un pour le débogueur Java et un pour LLDB, de sorte que vous pouvez inspecter les points d’arrêt dans votre code Java et natif sans redémarrer votre application ou modifier votre configuration de débogage.

Dans la figure 2, remarquez les deux onglets à droite du titre de la fenêtre Debug. Comme l’app comporte à la fois du code Java et C++, un onglet est destiné au débogage du code natif, et l’autre au débogage du code Java, comme indiqué par -java.

Figure 2. Onglet pour le débogage du code natif et onglet pour le débogage du code Java

Note : Si vous déboguez du code natif qui est optimisé par le compilateur, vous pouvez obtenir le message d’avertissement suivant : This function was compiled with optimizations enabled. Some debugger features may not be available. Lorsque vous utilisez des drapeaux d’optimisation, tels que les drapeaux -O, le compilateur apporte des modifications à votre code compilé pour le rendre plus efficace. Cela peut amener le débogueur à signaler des informations inattendues ou incorrectes, car il lui est difficile de faire correspondre le code compilé optimisé au code source d’origine. Pour cette raison, vous devriez désactiver les optimisations du compilateur pendant le débogage de votre code natif.

Utiliser le journal système

Le journal système affiche les messages système pendant que vous déboguez votre app. Ces messages comprennent desinformations provenant des apps exécutées sur l’appareil. Si vous voulez utiliser le journal système pour déboguer votre app, assurez-vous que votre code écrit des messages de journal et imprime le stacktrace pour les exceptions pendant que votre app est en phase de développement.

Écrire des messages de journal dans votre code

Pour écrire des messages de journal dans votre code, utilisez la classe Log. Les messages de journal vous aident à comprendre le flux d’exécution en recueillant la sortie de débogage du système pendant que vous interagissez avec votre application. Les messages de journal peuvent vous indiquer quelle partie de votre application a échoué. Pour plus d’informations sur la journalisation, voir Écrire et afficher des journaux.

L’exemple suivant montre comment vous pourriez ajouter des messages de journal pour déterminer si des informations sur l’état précédent sont disponibles lorsque votre activité démarre :

Pendant le développement, votre code peut également attraper des exceptions et écrire la trace de la pile dans le journal système :

Note : Supprimez les messages de journal de débogage et les appels d’impression de la trace de la pile de votre code lorsque vous êtes prêt à publier votre app. Vous pourriez le faire en définissant un DEBUGflag et en plaçant les messages du journal de débogage à l’intérieur des déclarations conditionnelles.

Voir le journal du système

Vous pouvez voir et filtrer les messages de débogage et autres messages du système dans la fenêtre Logcat. Par exemple, vous pouvez voir les messages lorsque le garbage collection se produit, ou les messages que vous ajoutez à votre app avec la classe Log.

Pour utiliser logcat, démarrez le débogage et sélectionnez l’onglet Logcat dans la barre d’outils inférieure, comme indiqué sur la figure 3.

Figure 3. Fenêtre Logcat avec paramètres de filtrage

Pour une description de logcat et de ses options de filtrage, voir Écrire et afficher des journaux avec Logcat.

Travailler avec des points d’arrêt

Android Studio prend en charge plusieurs types de points d’arrêt quidéclenchent différentes actions de débogage. Le type le plus courant est un point d’arrêt de lignequi met en pause l’exécution de votre application à une ligne de code spécifiée. Pendant la pause,vous pouvez examiner les variables, évaluer les expressions, puis poursuivre l’exécution ligne par ligne pour déterminer les causes des erreurs d’exécution.

Pour ajouter un point d’arrêt de ligne, procédez comme suit :

1. Localisez la ligne de code où vous souhaitez mettre l’exécution en pause, puis cliquez sur la gouttière gauche le long de cette ligne de code ou placez le signe d’insertion sur la ligne et appuyez sur Control+F8 (sur Mac, Command+F8).
2. Si votre application est déjà en cours d’exécution, vous n’avez pas besoin de la mettre à jour pour ajouter le point d’arrêt – cliquez simplement sur Attacher le débogueur au processus Android . Sinon, lancez le débogage en cliquant sur Debug .

Figure 3. Un point rouge apparaît à côté de la ligne lorsque vous définissez un point d’arrêt

Lorsque l’exécution de votre code atteint le point d’arrêt,Android Studio met en pause l’exécution de votre application. Vous pouvez alors utiliser les outils de l’onglet Débogueur pour identifier l’état de l’app :

• Pour examiner l’arbre d’objets d’une variable, développez-la dans la vue Variables. Si la vue Variables n’est pas visible, cliquez sur Restaurer la vue Variables .

• Pour évaluer une expression au point d’exécution actuel, cliquez sur Évaluer l’expression .

• Pour passer à la ligne suivante dans le code (sans entrer dans une méthode), cliquez sur Dépasser .

• Pour passer à la première ligne à l’intérieur d’un appel de méthode, cliquez sur Step Into .

• Pour passer à la ligne suivante en dehors de la méthode actuelle, cliquez sur Step Out .

• Pour continuer à exécuter l’application normalement, cliquez sur Resume Program .

Si votre projet utilise du code natif, par défaut, le type de débogage Auto attache à la fois le débogueur Java et LLDB à votre application en tant que deux processus distincts, de sorte que vous pouvez basculer entre l’inspection des points d’arrêt Java et C/C++ sans redémarrer votre application ou modifier les paramètres.

Remarque : pour qu’Android Studio détecte les points d’arrêt dans votre code C ou C++, vous devez utiliser un type de débogage qui prend en charge LLDB, comme Auto, Native ou Dual. Vous pouvez modifier le type de débogage utilisé par Android Studio en modifiant votre configuration de débogage. Pour en savoir plus sur les différents types de débogage, lisez la section relative à l’utilisation d’autres types de débogage.

Lorsqu’Android Studio déploie votre application sur votre appareil cible, la fenêtre de débogage s’ouvre avec un onglet ou une vue de session de débogage pour chaque processus de débogage, comme le montre la figure 4.

Figure 4. Débogage de code natif à l’aide de LLDB

1. Android Studio passe à l’onglet <votre-module> lorsque le débogueur LLDB rencontre un point d’arrêt dans votre code C/C++. Les volets Frames, Variables et Watches sont également disponibles et fonctionnent exactement comme ils le feraient si vous déboguiez du code Java. Bien que le volet Threads ne soit pas disponible dans la vue de la session LLDB, vous pouvez accéder aux processus de votre application à l’aide de la liste déroulante du volet Frames. Vous pouvez en savoir plus sur ces volets dans les sections sur la façon de déboguer les cadres de fenêtre et d’inspecter les variables.

   Remarque : pendant l’inspection d’un point d’arrêt dans votre code natif, le système Android suspend la machine virtuelle qui exécute le bytecode Java de votre application. Cela signifie que vous êtes incapable d’interagir avec le débogueur Java ou de récupérer des informations d’état de votre session de débogueur Java pendant l’inspection d’un point d’arrêt dans votre code natif.

2. Android Studio passe à l’onglet <votre-module>-java lorsque le débogueur Java rencontre un point d’arrêt dans votre code Java.
3. Lorsque vous déboguez avec LLDB, vous pouvez utiliser le terminal LLDB dans la vue de la session LLDB pour passer des options de ligne de commande à LLDB. Si vous avez certaines commandes que vous voudriez que LLDB exécute chaque fois que vous commencez à déboguer votre application, soit juste avant ou juste après que le débogueur s’attache à votre processus d’application, vous pouvez ajouter ces commandes à votre configuration de débogage.

Lors du débogage du code C/C++, vous pouvez également définir des types spéciaux de points d’arrêt, appelés points de surveillance, qui peuvent suspendre le processus de votre app lorsque celle-ci interagit avec un bloc de mémoire particulier. Pour en savoir plus, lisez la section sur la façon d’ajouter des points de surveillance.

Afficher et configurer les points d’arrêt

Pour afficher tous les points d’arrêt et configurer les paramètres des points d’arrêt, cliquez sur Afficher les points d’arrêt sur le côté gauche de la fenêtre de débogage. La fenêtre Points d’arrêt apparaît, comme le montre la figure 5.

Figure 5. La fenêtre Points d’arrêt répertorie tous les points d’arrêt actuels et comprend des paramètres de comportement pour chacun

La fenêtre Points d’arrêt vous permet d’activer ou de désactiver chaque point d’arrêt dans la liste de gauche. Si un point d’arrêt est désactivé, Android Studio ne met pas votre application en pause lorsqu’elle atteint ce point d’arrêt. Sélectionnez un point d’arrêt dans la liste pour configurer ses paramètres. Vous pouvez configurer un point d’arrêt pour qu’il soit désactivé au départ et que le système l’active après l’atteinte d’un autre point d’arrêt. Vous pouvez également configurer si un point d’arrêt doit être désactivé après avoir été touché. Pour définir un point d’arrêt pour n’importe quelle exception, sélectionnez Points d’arrêt d’exception dans la liste des points d’arrêt.

Cadres de la fenêtre de débogage

Dans la fenêtre du débogueur, le volet Cadres vous permet d’inspecter la trame de pile qui a provoqué l’atteinte du point d’arrêt actuel. Vous pouvez ainsi naviguer et examiner la trame de pile et également inspecter la liste des threads de votre application Android. Pour sélectionner un thread, utilisez la liste déroulante du sélecteur de thread et affichez sa trame de pile. En cliquant sur les éléments du cadre, vous ouvrez la source dans l’éditeur. Vous pouvez également personnaliser la présentation des threads et exporter le cadre de pile, comme indiqué dans le guide Fenêtre Frames.

Inspecter les variables

Dans la fenêtre Debugger, le volet Variables vous permet d’inspecter les variables lorsque le système arrête votre app sur un point d’arrêt et que vous sélectionnez un cadre dans le volet Frames. Le volet Variables vous permet également d’évaluer des expressions ad hoc en utilisant des méthodes statiques et/ou des variables disponibles dans le cadre sélectionné.

Le volet Veilles offre une fonctionnalité similaire, sauf que les expressions ajoutées au volet Veilles persistent entre les sessions de débogage. Vous devriez ajouter des veilles pour les variables et les champs auxquels vous accédez fréquemment ou qui fournissent un état utile pour la session de débogage en cours. Les volets Variables et Veilles apparaissent comme illustré à la figure 5.

Pour ajouter une variable ou une expression à la liste Veilles, suivez ces étapes :

1. Débogage en cours.
2. Dans le volet des veilles, cliquez sur Ajouter .
3. Dans la zone de texte qui apparaît, tapez le nom de la variable ou de l’expression que vous voulez surveiller, puis appuyez sur Entrée.

Pour supprimer un élément de la liste des surveillances, sélectionnez l’élément puis cliquez sur Supprimer .

Vous pouvez réorganiser les éléments de la liste des surveillances en sélectionnant un élément puis en cliquant sur Haut ou Bas .

Figure 6. Les volets Variables et Veilles de la fenêtre du débogueur

Ajouter des points de surveillance

Lors du débogage du code C/C++, vous pouvez définir des types spéciaux de points d’arrêt, appelés points de surveillance, qui peuvent suspendre le processus de votre app lorsque celle-ci interagit avec un bloc de mémoire particulier. Par exemple, si vous définissez deux pointeurs vers un bloc de mémoire et que vous lui attribuez un point de surveillance, l’utilisation de l’un ou l’autre pointeur pour accéder à ce bloc de mémoire déclenche le point de surveillance.

Dans Android Studio, vous pouvez créer un point de surveillance pendant l’exécution en sélectionnant une variable spécifique, mais LLDB attribue le point de surveillance uniquement au bloc de mémoire que le système alloue à cette variable, et non à la variable elle-même. Ceci est différent de l’ajout d’une variable au volet Watches, qui vous permet d’observer la valeur d’une variable mais ne vous permet pas de suspendre votre processus d’app lorsque le système lit ou modifie sa valeur en mémoire.

Remarque : Lorsque votre processus d’app quitte une fonction et que le système désalloue ses variables locales de la mémoire, vous devez réaffecter tous les points de surveillance que vous avez créés pour ces variables.

Pour définir un point de surveillance, vous devez répondre aux exigences suivantes :

• Votre périphérique physique cible ou votre émulateur utilise un CPU x86 ou x86_64. Si votre périphérique utilise un CPU ARM, alors vous devez aligner la limite de l’adresse de votre variable en mémoire soit sur 4 octets pour les processeurs 32 bits, soit sur 8 octets pour les processeurs 64 bits. Vous pouvez aligner une variable dans votre code natif en spécifiant __attribute__((aligned(num_bytes))) dans le ralentissement de la variable, comme indiqué ci-dessous :

  // For a 64-bit ARM processorint my_counter __attribute__((aligned(8)));

• Vous avez déjà attribué trois points de surveillance ou moins. Android Studio ne prend en charge que jusqu’à quatre points de surveillance sur les périphériques cibles x86 ou x86_64. D’autres périphériques peuvent prendre en charge moins de points de surveillance.

Remarque : lors du débogage de votre application avec les ABI ARM 32 bits, l’ajout d’un point de surveillance ou le survol de variables à l’intérieur du code pour enquêter sur leurs valeurs peut provoquer un crash. Comme solution de contournement, veuillez déboguer en utilisant des binaires ARM 64 bits, x86 ou x86_64. Ce problème sera corrigé dans une prochaine version d’Android Studio.

Si vous remplissez les conditions ci-dessus, vous pouvez ajouter un point de surveillance comme suit :

1. Alors que votre application est suspendue sur un point d’arrêt, naviguez vers le volet Variables dans votre vue de session LLDB.

2. Cliquez avec le bouton droit sur une variable qui occupe le bloc de mémoire que vous voulez suivre et sélectionnez Ajouter un point de surveillance. Une boîte de dialogue permettant de configurer votre point de surveillance apparaît, comme le montre la figure 7.

   

   Figure 7. Ajout d’un point de surveillance à une variable en mémoire

3. Configurez votre point de surveillance avec les options suivantes :
   • Activé : Vous pouvez désélectionner cette option si vous souhaitez indiquer à Android Studio d’ignorer le point de surveillance pour le moment. Android Studio enregistre toujours votre point de surveillance afin que vous puissiez y accéder plus tard dans votre session de débogage.
   • Suspendre : Par défaut, le système Android suspend le processus de votre application lorsqu’il accède à un bloc de mémoire que vous affectez à un point de surveillance. Vous pouvez désélectionner cette option si vous ne voulez pas ce comportement-ce qui révèle des options supplémentaires que vous pouvez utiliser pour personnaliser le comportement lorsque le système interagit avec votre point de surveillance : Enregistrer le message dans la console et Supprimer lorsqu’il est touché.
   • Type d’accès : Sélectionnez si votre application doit déclencher votre point de surveillance lorsqu’elle tente de lire ou d’écrire dans le bloc de mémoire que le système alloue à la variable. Pour déclencher votre point de surveillance sur une lecture ou une écriture, sélectionnez Any.
4. Cliquez sur Terminé.

Pour visualiser tous vos points de surveillance et configurer les paramètres des points de surveillance, cliquez sur View Breakpoints sur le côté gauche de la fenêtre Debug. Le dialogue Points d’arrêt apparaît, comme illustré à la figure 8.

Figure 8. La boîte de dialogue Breakpoints répertorie vos points de surveillance actuels et inclut les paramètres de comportement pour chacun

Après avoir ajouté votre point de surveillance, cliquez sur Resume Program sur le côté gauche de la fenêtre Debug pour reprendre le processus de votre app. Par défaut, si votre app tente d’accéder à un bloc de mémoire sur lequel vous avez défini un point de surveillance, le système Android suspend le processus de votre app et une icône de point de surveillance apparaît à côté de la ligne de code que votre app a exécutée en dernier, comme le montre la figure 9.

Figure 9. Android Studio indique la ligne de code que votre app exécute juste avant de déclencher un point de surveillance

Voir et modifier le format d’affichage des valeurs de ressources

En mode débogage, vous pouvez voir les valeurs de ressources et sélectionner un format d’affichage différent pour les variables de votre code Java. Avec l’onglet Variables affiché et un cadre sélectionné, procédez comme suit :

1. Dans la liste Variables, cliquez avec le bouton droit de la souris n’importe où sur une ligne de ressource pour afficher la liste déroulante.
2. Dans la liste déroulante, sélectionnez Afficher sous et sélectionnez le format que vous voulez utiliser.

   Les formats disponibles dépendent du type de données de la ressource que vous avez sélectionnée. Vous pouvez voir une ou plusieurs des options suivantes :

   • Classe : Afficher la définition de la classe.
   • toString : Afficher le format de la chaîne de caractères.
   • Objet : Afficher la définition de l’objet (une instance d’une classe).
   • Tableau : Afficher dans un format de tableau.
   • Horodatage : Afficher la date et l’heure de la manière suivante : aaaa-mm-jj hh:mm:ss.
   • Auto : Android Studio choisit le meilleur format en fonction du type de données.
   • Binaire : Afficher une valeur binaire en utilisant des zéros et des uns.
   • MeasureSpec : La valeur transmise par le parent à l’enfant sélectionné. Voir MeasureSpec.
   • Hex : Affichage comme une valeur hexadécimale.
   • Primitive : Afficher comme une valeur numérique en utilisant un type de données primitif.
   • Entier : Afficher une valeur numérique de type Integer.

Vous pouvez créer un format personnalisé (restituteur de type de données), comme suit :

.