Cette page a été traduite par l'API Cloud Translation.

Déboguer votre application

Android Studio fournit un débogueur permettant d'effectuer les opérations suivantes, entre autres :

Sélectionner un appareil sur lequel 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 lors de l'exécution

Cette page explique comment effectuer les opérations de débogage de base. Pour en savoir plus, consultez également la documentation sur le débogage avec IntelliJ IDEA.

Activer le débogage

Avant de commencer le débogage, procédez comme suit :

Activez le débogage sur votre appareil :

Le débogage est activé par défaut dans l'émulateur. En revanche, pour un appareil connecté, vous devez activer le débogage dans les options pour développeurs de l'appareil.

Exécutez une variante de compilation débogable :

Utilisez une variante de compilation qui inclut debuggable true (isDebuggable = true dans les scripts Kotlin) dans sa configuration.

En règle générale, vous pouvez sélectionner la variante "debug" incluse par défaut dans tous les projets Android Studio, même si elle n'est pas visible dans le fichier build.gradle. Toutefois, si vous définissez de nouveaux types de compilation qui doivent être débogables, vous devez ajouter debuggable true au type de compilation :

Groovy

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

Kotlin

android {
    buildTypes {
        create("customDebugType") {
            isDebuggable = true
            ...
        }
    }
}

Cette propriété s'applique également aux modules avec du code C/C++.

Remarque : 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 pour conserver ses symboles de débogage. Pour vous assurer que les variantes débogables de votre projet d'application reçoivent la variante débogable d'un module de bibliothèque, publiez les versions autres que celles par défaut de votre bibliothèque.

Démarrer le débogage

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

Définissez des points d'arrêt dans le code de votre application.
Dans la barre d'outils, ouvrez le menu des appareils cibles et sélectionnez un appareil sur lequel déboguer votre application.

Figure 1. Menu des appareils cibles

Si vous n'avez configuré aucun appareil, vous devez connecter un appareil via USB ou via le Wi-Fi, ou créer un AVD pour utiliser Android Emulator.
Dans la barre d'outils, cliquez sur Debug (Débogage) .
Si votre application est déjà en cours d'exécution sur l'appareil, une boîte de dialogue s'affiche et vous invite à passer de l'exécution au débogage. L'appareil doit redémarrer pour lancer le débogage. Pour continuer à exécuter la même instance de l'application, cliquez sur Cancel Debug (Annuler le débogage), puis associez le débogueur à votre application en cours d'exécution. Sinon, Android Studio compile 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" (Débogage) pour déboguer votre code natif.
Si la fenêtre "Debug" (Débogage) n'est pas ouverte, sélectionnez View > Tool Windows > Debug (Affichage > Fenêtres d'outils > Débogage) ou cliquez sur Debug dans la barre des fenêtres d'outils.

Associer le débogueur à une appli en cours d'exécution

Si votre application est déjà en cours d'exécution sur votre appareil, vous pouvez lancer le débogage sans la redémarrer :

Cliquez sur Attach debugger to Android process (Associer le débogueur à un processus Android).
Dans la boîte de dialogue Choose Process (Sélectionner un processus), sélectionnez le processus auquel vous souhaitez associer le débogueur.
1. Si vous utilisez un émulateur ou un appareil en mode root, vous pouvez cocher la case Show all processes (Afficher tous les processus) pour afficher tous les processus. Sur un appareil en mode root, tous les processus en cours d'exécution sont affichés. Toutefois, sur un appareil qui n'est pas en mode root, seuls les processus débogables s'affichent.
2. Le menu Use Android Debugger Settings from (Sélectionner les paramètres du débogueur Android) vous permet d'appliquer une configuration d'exécution/de débogage préexistante. Pour le code C et C++, cela vous permet de réutiliser les commandes LLDB de démarrage et post-association, ainsi que les répertoires de symboles d'une configuration existante.
3. Si vous n'avez pas encore de configuration d'exécution/de débogage, sélectionnez Create New (Créer). Cette sélection active le menu Debug Type (Type de débogage), qui vous permet de sélectionner un autre type de débogage. Par défaut, Android Studio utilise le type de débogage "Detect Automatically" (Détecter automatiquement) pour sélectionner l'option de débogage la plus adaptée à votre projet, selon que votre projet inclut du code Java ou C/C++.
Cliquez sur OK.
La fenêtre "Debug" (Débogage) s'affiche.

L'onglet Processes (Processus) de l'Explorateur de l'appareil (View > Tool Windows > Device Explorer [Vue > Fenêtres d'outils > Explorateur de l'appareil]) contient également une liste de processus débogables. Vous pouvez alors sélectionner un processus et l'arrêter , en forcer l'arrêt , ou joindre le débogueur à un processus donné .

Fenêtre de débogage

Composition de la fenêtre de débogage :

Barre d'outils d'exécution et de navigation. Consultez la page Utiliser des points d'arrêt.
Sélecteur de thread.
Évaluation et surveillance de l'entrée de l'expression. Consultez Inspecter les variables.
Affichage de la pile.
Volet des variables. Consultez Inspecter les variables.

Remarque : Le débogueur et le récupérateur de mémoire d'Android Studio interagissent en couplage lâche. La machine virtuelle Android garantit que tous les objets dont le débogueur a connaissance sont exemptés de la récupération de mémoire jusqu'à la déconnexion du débogueur. Cela peut entraîner une accumulation d'objets lorsque le débogueur reste connecté. Par exemple, si le débogueur analyse un thread en cours d'exécution, l'objet Thread associé n'est pas éliminé par la récupération de mémoire, même si le thread prend fin, et persiste jusqu'à la déconnexion du débogueur.

Modifier le type de débogueur

Étant donné que le code Java/Kotlin et le code C/C++ nécessitent différents outils de débogage, Android Studio vous permet de sélectionner le type de débogueur à utiliser. Par défaut, Android Studio détermine le débogueur à utiliser en fonction des langues qu'il détecte dans votre projet lorsque le type de débogage est défini sur Detect Automatically (Détecter automatiquement).

Vous pouvez sélectionner manuellement le débogueur dans la configuration de débogage en cliquant sur Run > Edit Configurations (Exécuter > Modifier les configurations) ou dans la boîte de dialogue qui s'affiche lorsque vous cliquez sur Run > Attach debugger to Android process (Exécuter > Associer le débogueur à un processus Android).

Les types de débogueur disponibles sont les suivants :

Détecter automatiquement

Sélectionnez ce type de débogueur si vous souhaitez qu'Android Studio détermine automatiquement la meilleure option pour le code à déboguer. Par exemple, si votre projet comporte du code C ou C++, Android Studio utilise automatiquement le type de débogage "Dual" (Double). Sinon, Android Studio utilise uniquement le type de débogage Java.

Java uniquement

Sélectionnez ce type de débogueur si vous souhaitez déboguer uniquement le code écrit en Java ou Kotlin. Le débogueur Java uniquement ignore les points d'arrêt ou d'observation que vous avez définis dans votre code natif.

Natif uniquement (code C/C++ uniquement)

Sélectionnez ce type de débogueur si vous souhaitez exclusivement utiliser LLDB pour déboguer votre code. Lorsque vous utilisez ce type, la vue de session du débogueur Java n'est pas disponible. Par défaut, LLDB n'inspecte que 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 choisir le type de débogage "Detect Automatically" (Détecter automatiquement) ou "Dual" (Double).

Le débogage natif ne fonctionne que sur les appareils qui répondent aux critères suivants :

L'appareil est compatible avec run-as.

Pour vérifier si l'appareil est compatible avec run-as, exécutez la commande suivante sur l'interface système ADB connectée à votre appareil :
```
run-as your-package-name pwd
```
Remplacez your-package-name par le nom du package de votre application. Si l'appareil est compatible avec run-as, la commande ne devrait renvoyer aucune erreur.
ptrace est activé sur l'appareil.

Pour vérifier si ptrace est activé, exécutez la commande suivante sur l'interface système ADB connectée à votre appareil :
```
sysctl kernel.yama.ptrace_scope
```
Si ptrace est activé, la commande renvoie la valeur 0 ou une erreur unknown key. Si ptrace n'est pas activé, une valeur autre que 0 s'affiche.

Double (Java + natif) – disponible uniquement avec du code C/C++

Sélectionnez ce type de débogueur si vous souhaitez passer du débogage Java au code natif et inversement. Android Studio associe deux débogueurs (Java et LLDB) à votre processus d'application, vous permettant d'inspecter les points d'arrêt dans votre code Java et natif sans redémarrer votre application ni modifier votre configuration de débogage.

Dans la figure 2, vous remarquerez les deux onglets situés à droite du titre de la fenêtre "Debug". Comme l'application utilise à la fois du code Java et C++, l'un de ces onglets sert à déboguer le code natif, et l'autre à déboguer le code Java (signalé par le suffixe -java).

**Figure 3**. Onglets de débogage dédiés respectivement au code natif et au code Java

Remarque : Lorsque vous déboguez du code natif optimisé par le compilateur, le message d'avertissement suivant peut s'afficher :
This function was compiled with optimizations enabled. Some debugger features may not be available. Lorsque vous utilisez des indicateurs d'optimisation, le compilateur adapte le mode de compilation pour une exécution plus efficace. Cette opération peut amener le débogueur à rapporter des informations inattendues ou incorrectes, car il rencontre des difficultés pour mapper le code compilé optimisé au code source d'origine. Pour éviter ce problème, vous devez 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 du système pendant que vous déboguez votre application. Ces messages incluent des informations provenant d'applications exécutées sur l'appareil. Si vous souhaitez utiliser le journal système pour déboguer votre application, assurez-vous que votre code écrit des messages de journal et imprime la trace de la pile pour les exceptions tant que votre application 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 aident à comprendre le flux d'exécution en collectant les résultats du débogage système pendant que vous interagissez avec votre application. Ils peuvent aussi vous indiquer quelle partie de votre application ne fonctionne pas correctement. Pour en savoir plus sur la journalisation, consultez Écrire et afficher des journaux avec Logcat.

L'exemple suivant montre comment ajouter des messages de journal pour déterminer si des informations sur l'état antérieur sont disponibles lorsque votre activité commence :

Kotlin

import android.util.Log
...
class MyActivity : Activity() {
    ...
    override fun onCreate(savedInstanceState: Bundle?) {
        ...
        if (savedInstanceState != null) {
            Log.d(TAG, "onCreate() Restoring previous state")
            /* restore state */
        } else {
            Log.d(TAG, "onCreate() No saved state available")
            /* initialize app */
        }
        ...
    }
  ...
  companion object {
    private val TAG: String = MyActivity::class.java.simpleName
    ...
  }
}

Java

import android.util.Log;
...
public class MyActivity extends Activity {
    private static final String TAG = MyActivity.class.getSimpleName();
    ...
    @Override
    public void onCreate(Bundle savedInstanceState) {
       ...
       if (savedInstanceState != null) {
            Log.d(TAG, "onCreate() Restoring previous state");
            /* restore state */
        } else {
            Log.d(TAG, "onCreate() No saved state available");
            /* initialize app */
        }
        ...
    }
}

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

Kotlin

fun someOtherMethod() {
    try {
        ...
    } catch (e : SomeException) {
        Log.d(TAG, "someOtherMethod()", e)
    }
}

Java

void someOtherMethod() {
    try {
        ...
    } catch (SomeException e) {
        Log.d(TAG, "someOtherMethod()", e);
    }
}

Remarque : Lorsque vous êtes prêt à publier votre application, supprimez de votre code les messages de journal de débogage et les appels d'impression de trace de la pile. Pour cela, définissez un indicateur DEBUG et placez les messages de journal de débogage dans des instructions conditionnelles.

Consulter le journal système

Vous pouvez afficher et filtrer les messages de débogage et d'autres messages système dans la fenêtre "Logcat", comme illustré dans la figure 4. Par exemple, vous pouvez cibler les messages liés à la récupération de mémoire ou ceux que vous ajoutez à votre application avec la classe Log.

Pour utiliser Logcat, démarrez le débogage et sélectionnez l'onglet "Logcat".

**Figure 4**. Fenêtre "Logcat" avec les paramètres de filtre

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

Utiliser des points d'arrêt

Android Studio est compatible avec des points d'arrêt qui déclenchent différentes actions de débogage. Il existe plusieurs types de points d'arrêt :

Point d'arrêt de ligne: Le type le plus courant est un point d'arrêt qui suspend l'exécution de votre application sur une ligne de code spécifiée. Pendant la mise en suspens, vous pouvez examiner les variables, évaluer les expressions, puis continuer l'exécution ligne par ligne pour déterminer les causes d'erreurs.
Point d'arrêt de méthode: Un point d'arrêt de méthode suspend l'exécution de votre application lorsqu'elle passe à une méthode spécifique ou la quitte. Pendant la mise en suspens, vous pouvez examiner les variables, évaluer les expressions, puis continuer l'exécution ligne par ligne pour déterminer les causes d'erreurs. Lorsque vous définissez un point d'arrêt sur une fonction composable, le débogueur liste les paramètres du composable et leur état pour vous aider à identifier les modifications qui ont pu provoquer la recomposition.
Point d'arrêt de champ: Un point d'arrêt de champ suspend l'exécution de votre application lorsqu'elle lit ou écrit dans un champ spécifique.
Point d'arrêt sur exception: Un point d'arrêt sur exception suspend l'exécution de votre application lorsqu'une exception est générée.

Vous pouvez définir des points d'arrêt conditionnels qui ne suspendront l'exécution que si des conditions spécifiques sont remplies. Vous pouvez également définir des points d'arrêt de journalisation qui écrivent des données dans Logcat sans suspendre l'exécution. Vous éviterez ainsi de polluer votre code avec des instructions de journalisation.

Pour ajouter un point d'arrêt, procédez comme suit :

Repérez la ligne de code à laquelle vous souhaitez interrompre l'exécution.
Cliquez sur la gouttière gauche le long de cette ligne de code, ou placez le curseur de saisie sur la ligne et appuyez sur Ctrl+F8 (Commande+F8 sous macOS).
Si votre application est déjà en cours d'exécution, cliquez sur Attach debugger to Android process (Associer le débogueur à un processus Android) . Sinon, pour lancer le débogage, cliquez sur Debug (Déboguer) .

Un point rouge apparaît à côté de la ligne lorsque vous définissez un point d'arrêt, comme illustré dans la figure 5.

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

Lorsque l'exécution du code atteint le point d'arrêt, Android Studio suspend l'exécution de votre application.

Pour identifier l'état de l'application, utilisez les outils de l'onglet "Debugger" (Débogueur) :

Pour rechercher une variable dans l'arborescence des objets, développez-la dans la vue "Variables". Si la vue "Variables" n'est pas visible, cliquez sur Layout Settings (Paramètres de mise en page) et assurez-vous que l'option variables est cochée.
Pour passer à la ligne de code suivante sans saisir de méthode, cliquez sur Step Over (Passer) .
Pour passer à la première ligne d'un appel de méthode, cliquez sur Step into (Descendre) .
Pour passer à la ligne suivante en dehors de la méthode actuelle, cliquez sur Remonter .
Pour continuer l'exécution normale de l'appli, cliquez sur Resume Program (Reprendre le programme) .

Si votre projet utilise du code natif, le type de débogage "Detect Automatically" (Détecter Automatiquement) associe les débogueurs Java et LLDB à votre application sous la forme de deux processus distincts. Vous pouvez ainsi basculer entre l'inspection du code Java et celle des points d'arrêt C/C++ sans redémarrer votre appli ni 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ébogueur compatible avec LLDB, tel que "Detect automatically" (Détecter automatiquement), "Native" (Natif) ou "Dual" (Double). Vous pouvez changer le type de débogueur utilisé par Android Studio en modifiant votre configuration de débogage. Pour en savoir plus sur les différents types de débogueurs, consultez la section Modifier le type de débogueur.

Lorsqu'Android Studio déploie votre application sur l'appareil cible, la fenêtre "Debug" (Débogage) s'ouvre avec un onglet ou une vue de session pour chaque processus de débogage, comme illustré dans la figure 6.

**Figure 6**. Débogage de code natif à l'aide de LLDB

Android Studio affiche l'onglet <your-module> lorsque le débogueur LLDB rencontre un point d'arrêt dans votre code C/C++. Les volets "Frames", "Variables" et "Watches" (Points d'observation) sont également disponibles et fonctionnent exactement comme si vous déboguiez du code Java.

Bien que le volet "Threads" ne soit pas disponible dans la vue de session LLDB, vous pouvez accéder aux processus de votre application à l'aide de la liste du volet "Frames". Pour en savoir plus sur ces volets, consultez les sections Déboguer les frames de fenêtre et Inspecter les variables.
Remarque : Lorsqu'un point d'arrêt est inspecté 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 ne pouvez pas interagir avec le débogueur Java ni récupérer des informations d'état à partir de votre session de débogage Java lorsqu'un point d'arrêt est inspecté dans votre code natif.
Android Studio bascule sur l'onglet <your-module>-java lorsque le débogueur Java rencontre un point d'arrêt dans le code Java ou Kotlin.
Lors du débogage avec LLDB, vous pouvez utiliser le terminal LLDB dans la vue de session LLDB pour transmettre les options de ligne de commande à LLDB. Si vous souhaitez que LLDB exécute certaines commandes chaque fois que vous commencez à déboguer votre application, que ce soit juste avant ou juste après l'association du débogueur au processus de votre application, vous pouvez ajouter des commandes à votre configuration de débogage.

Afficher et configurer des points d'arrêt

Pour afficher tous les points d'arrêt et configurer les paramètres correspondants, cliquez sur View Breakpoints (Afficher les points d'arrêt) dans la fenêtre "Debug" (débogage). La fenêtre "Breakpoints" (Points d'arrêt) s'affiche, comme illustré dans la figure 7.

**Figure 7**. La fenêtre "Breakpoints" (Points d'arrêt) liste tous les points d'arrêt actuels et inclut leurs paramètres de comportement respectifs.

La fenêtre "Breakpoints" (Points d'arrêt) vous permet d'activer ou de désactiver chaque point d'arrêt depuis la liste du volet. Si un point d'arrêt est désactivé, Android Studio ne suspend pas l'exécution de votre application lorsque ce point est atteint.

Sélectionnez un point d'arrêt dans la liste pour configurer ses paramètres. Vous pouvez configurer un point d'arrêt pour le désactiver dans un premier temps et laisser le système l'activer lorsqu'un autre point d'arrêt est atteint. Vous pouvez également configurer si un point d'arrêt doit être désactivé après avoir été atteint. Pour définir un point d'arrêt pour une exception, sélectionnez Exception Breakpoints (Points d'arrêt sur exception) dans la liste des points d'arrêt.

Pour désactiver temporairement tous les points d'arrêt, cliquez sur Mute Breakpoints (Désactiver les points d'arrêt) dans la fenêtre de débogage. Cliquez à nouveau sur l'icône pour les réactiver.

Déboguer les frames de fenêtre

Dans la fenêtre "Debugger" (Débogueur), le volet "Frames" permet de vérifier le bloc de pile qui a provoqué l'activation du point d'arrêt actuel. Vous pouvez ainsi parcourir et examiner le bloc de pile, et inspecter la liste des threads de votre application Android

Pour sélectionner un thread, utilisez le menu du sélecteur et affichez son bloc de pile. Cliquez sur les éléments du frame pour ouvrir la source dans l'éditeur. Vous pouvez également personnaliser la présentation du thread et exporter le bloc de pile, comme indiqué dans le guide d'examen des frames.

Inspecter les variables

Dans la fenêtre "Debugger" (Débogueur), le volet "Variables" vous permet d'inspecter les variables lorsque le système suspend votre application sur un point d'arrêt et que vous sélectionnez un frame depuis le volet "Frames". Le volet "Variables" vous permet également d'évaluer des expressions ad hoc à l'aide de méthodes et/ou de variables statiques disponibles dans le frame sélectionné.

Pour ajouter une expression à l'arborescence des objets (lors du débogage de l'application):

Figure 8 : Arborescence des objets et zone de saisie des expressions dans la fenêtre de débogage.

Saisissez l'expression à surveiller ou à afficher
Cliquez sur Add to watches (Ajouter aux surveillances) ou appuyez sur Entrée pour évaluer l'expression une fois.

Si l'arborescence des objets contient l'expression que vous souhaitez surveiller, vous pouvez la faire glisser vers le haut de l'arborescence afin de l'ajouter en tant qu'expression surveillée.

Les expressions surveillées sont mises à jour lorsque des points d'arrêt sont atteints ou que vous parcourez votre code.

Les expressions évaluées resteront affichées en haut de l'arborescence des objets jusqu'à ce que vous évaluiez manuellement une autre expression ou parcouriez votre code.

Pour supprimer une expression surveillée de l'arborescence des objets, effectuez un clic droit sur l'expression, puis cliquez sur Remove Watch (Supprimer la surveillance).

Ajouter des points d'observation

Lors du débogage du code C/C++, vous pouvez également définir des points d'arrêt particuliers, appelés points d'observation, qui peuvent suspendre le processus de votre application lorsque celle-ci interagit avec un bloc de mémoire spécifique. Par exemple, si vous définissez deux pointeurs vers un bloc de mémoire et que vous lui assignez un point d'observation, l'utilisation de l'un ou l'autre de ces pointeurs pour accéder à ce bloc de mémoire déclenche le point d'observation.

Dans Android Studio, vous pouvez créer un point d'observation pendant l'exécution en sélectionnant une variable spécifique. Toutefois, LLDB affecte le point d'observation uniquement au bloc de mémoire que le système alloue à cette variable, et non à la variable elle-même. Cette opération diffère de l'ajout d'une variable au volet "Watches" (Points d'observation), qui vous permet d'observer la valeur d'une variable, mais pas de suspendre le processus de votre application lorsque le système lit ou modifie la valeur en mémoire.

Remarque : Lorsque le processus de votre application quitte une fonction et que le système libère les variables locales en mémoire, vous devez réaffecter les points d'observation créés pour ces variables.

Pour définir un point d'observation, vous devez remplir les conditions suivantes :

Votre appareil physique ou votre émulateur cible utilise un processeur x86 ou x86_64. Si votre appareil utilise un processeur ARM, vous devez aligner les limites d'adresse de votre variable sur 4 octets pour les processeurs 32 bits ou sur 8 octets pour les processeurs 64 bits. Pour aligner une variable dans votre code natif, spécifiez __attribute__((aligned(num_bytes))) dans la déclaration de variable, comme indiqué ci-dessous :
```
// For a 64-bit ARM processor
int my_counter __attribute__((aligned(8)));
```
Vous n'avez attribué que trois points d'observation au maximum. Android Studio ne prend en charge que quatre points d'observation sur les appareils cibles avec processeur x86 ou x86_64. Certains autres appareils peuvent gérer moins de points d'observation.

Remarque : Lorsque vous déboguez votre application avec des ABI ARM 32 bits, ajouter un point d'observation ou pointer sur les variables dans le code pour examiner leurs valeurs peut entraîner un plantage. Pour contourner ce problème, effectuez votre débogage à l'aide d'un fichier binaire ARM 64 bits, x86 ou x86_64. Ce problème sera résolu dans une prochaine version d'Android Studio.

Si vous remplissez les conditions, vous pouvez ajouter un point d'observation comme suit :

Pendant que votre application est suspendue au niveau du point d'arrêt, accédez au volet "Variables" de la vue de votre session LLDB.
Effectuez un clic droit sur une variable qui occupe le bloc de mémoire dont vous souhaitez effectuer le suivi, puis sélectionnez Add Watchpoint (Ajouter un point d'observation).

Figure 9. Ajout d'un point d'observation à une variable en mémoire.
Une boîte de dialogue permettant de configurer votre point d'observation s'affiche, comme illustré dans la figure 9.

Configurez votre point d'observation à l'aide des options suivantes :
- Enabled (Activer) : désélectionnez cette option si vous souhaitez qu'Android Studio ignore le point de contrôle jusqu'à ce que vous modifiiez le paramètre. Android Studio enregistrera votre point de contrôle pour vous permettre d'y accéder plus tard.
- Suspend (Suspendre) : par défaut, le système Android suspend le processus de votre appli lorsqu'elle accède à un bloc de mémoire auquel vous assignez un point d'observation. Désélectionnez cette option si ce n'est pas le comportement recherché. Vous verrez alors d'autres options que vous pouvez utiliser pour personnaliser le comportement lorsque le système interagit avec votre point d'observation : Log message to console (Consigner un message dans la console) et Remove when hit (Supprimer lorsque le point d'observation est atteint).
- Access Type (Type d'accès) : indiquez si votre appli doit déclencher votre point d'observation 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 d'observation en lecture et en écriture, sélectionnez Any (Les deux).
Cliquez sur Done (OK).

Pour afficher tous vos points d'observation et configurer leurs paramètres, cliquez sur View Breakpoints (Afficher les points d'arrêt) dans la fenêtre "Debug" (Débogage). La boîte de dialogue "Breakpoints" (Points d'arrêt) s'affiche, comme illustré dans la figure 10.

**Figure 10**. La boîte de dialogue "Breakpoints" (Points d'arrêt) liste vos points d'observation actuels et inclut leurs paramètres de comportement respectifs.

Après avoir ajouté votre point d'observation, cliquez sur Resume Program (Reprendre le programme) dans la fenêtre "Debug" (Débogage) pour relancer le processus de l'application. Par défaut, si votre application tente d'accéder à un bloc de mémoire auquel vous avez assigné un point d'observation, le système Android suspend le processus. De plus, une icône de point d'observation s'affiche à côté de la dernière ligne de code exécutée par votre application, comme illustré dans la figure 11.

**Figure 11**. Android Studio indique la dernière ligne de code exécutée par votre application avant le déclenchement d'un point d'observation.

Afficher et modifier le format d'affichage des valeurs de ressources

En mode débogage, vous pouvez afficher les valeurs des ressources et sélectionner un autre format d'affichage pour les variables de votre code Java ou Kotlin. Affichez l'onglet "Variables", sélectionnez un frame, puis procédez comme suit :

Dans la liste "Variables", effectuez un clic droit n'importe où sur une ligne de ressources pour afficher une liste.
Dans la liste, sélectionnez View as (Format d'affichage), puis choisissez le format que vous souhaitez utiliser.
Les formats disponibles dépendent du type de données de la ressource sélectionnée. Une ou plusieurs des options suivantes peuvent s'afficher :
- Class (Classe) : affiche la définition de la classe.
- toString : affiche le format de la chaîne.
- Object (Objet) : affiche la définition de l'objet (instance d'une classe).
- Array (Tableau) : affiche les valeurs sous forme de tableau.
- Timestamp (Code temporel) : affiche la date et l'heure au format aaaa-mm-jj hh:mm:ss.
- Auto (Automatique) : Android Studio choisit le meilleur format en fonction du type de données.
- Binary (Binaire) : affiche une valeur binaire composée de zéros et de uns.
- MeasureSpec : la valeur transmise du parent à l'enfant sélectionné. Voir MeasureSpec.
- Hex : affiche la valeur au format hexadécimal.
- Primitive (Primitif) : affiche la valeur au format numérique à l'aide d'un type de données primitif.
- Integer (Entier) : affiche une valeur numérique de type Integer.

Pour créer un format personnalisé, procédez comme suit :

Effectuez un clic droit sur la valeur de la ressource.
Sélectionnez View as (Format d'affichage).
Sélectionnez Create (Créer).
La boîte de dialogue Java Data Type Renderers (Moteurs de rendu de types de données Java) s'affiche. Suivez les instructions dans la section Moteurs de rendu des types de données Java.