Suivi des erreurs Android
Présentation
La fonctionnalité de suivi des erreurs traite les erreurs recueillies à partir du SDK Android. Pour démarrer rapidement le suivi des erreurs, téléchargez la dernière version de dd-sdk-android.
Si votre code source Android mobile est obfusqué, importez votre fichier de mapping Proguard/R8 dans Datadog pour que vos différentes stack traces puissent être désobfusquées. Pour une erreur donnée, vous pouvez accéder au chemin du fichier, au numéro de ligne, ainsi qu’à un extrait de code pour chaque frame de la stack trace associée.
Importer votre fichier de mapping
- Ajoutez le plug-in Gradle à votre projet Gradle en utilisant l’extrait de code suivant.
// Dans le script build.gradle de votre application
plugins {
id("com.datadoghq.dd-sdk-android-gradle-plugin") version "x.y.z"
}
- Créez une nouvelle clé d’API Datadog dédiée et exportez-la en tant que variable d’environnement
DD_API_KEY
(vous pouvez également la transmettre en tant que propriété de tâche). - (Facultatif) Configurez le plug-in de façon à importer les fichiers sur le site européen en exportant deux variables d’environnement supplémentaires :
export DATADOG_SITE="datadoghq.eu"
et export DATADOG_API_HOST="api.datadoghq.eu"
. - Lancez la tâche d’importation une fois que votre APK obfusqué a été créé :
./gradlew uploadMappingRelease
Remarque : si votre projet utilise d’autres flavors, le plug-in fournit une tâche d’importation pour chaque variante sur laquelle l’obfuscation est activée. Dans ce cas, initialisez le SDK avec un nom de variante approprié (l’API nécessaire est disponible à partir de la version 1.8.0
).
- Ajoutez le plug-in Gradle à votre projet Gradle en utilisant l’extrait de code suivant.
// Dans le script build.gradle de votre application
plugins {
id("com.datadoghq.dd-sdk-android-gradle-plugin") version "x.y.z"
}
- Créez une nouvelle clé d’API Datadog dédiée et exportez-la en tant que variable d’environnement
DD_API_KEY
(vous pouvez également la transmettre en tant que propriété de tâche). - Configurez le plug-in de façon à utiliser le site européen en ajoutant l’extrait de code suivant dans le fichier de script
build.gradle
de votre application :
- Lancez la tâche d’importation une fois que votre APK obfusqué a été créé :
./gradlew uploadMappingRelease
Remarque : si votre projet utilise d’autres flavors, le plug-in fournit une tâche d’importation pour chaque variante sur laquelle l’obfuscation est activée. Dans ce cas, initialisez le SDK avec un nom de variante approprié (l’API nécessaire est disponible à partir de la version 1.8.0
).
Options de configuration du plug-in
Vous pouvez configurer plusieurs propriétés du plug-in à l’aide de l’extension. Si vous utilisez plusieurs variantes, vous pouvez définir une valeur de propriété pour une flavor spécifique dans la variante.
Exemple :
Pour une variante fooBarRelease
, la configuration suivante est possible :
datadog {
foo {
versionName = "foo"
}
bar {
versionName = "bar"
}
fooBar {
versionName = "fooBar"
}
}
La configuration de tâche pour cette variante sera fusionnée à partir des trois flavors fournis dans l’ordre suivant : bar
-> foo
-> fooBar
, ce qui permettra de résoudre la valeur finale pour la propriété versionName
en tant que : fooBar
Nom de la propriété | Description |
---|
versionName | Le nom de version de l’application. |
serviceName | Le nom de service de l’application. |
site | Le site Datadog vers lequel importer vos données (“US”, “EU” ou “GOV”). |
remoteRepositoryUrl | L’URL du référentiel distant où le code source a été déployé. Si cette valeur n’est pas fournie, elle sera résolue à partir de votre configuration GIT actuelle pendant le temps d’exécution de la tâche. |
checkProjectDependencies | Cette propriété définit si le plug-in doit vérifier si le SDK Datadog est inclus dans les dépendances et effectuer l’action suivante si ce n’est pas le cas : « none » - ignorer, « warn » - envoyer un avertissement, « fail » - faire échouer le build avec une erreur (par défaut). |
Dépanner les erreurs
Une stack trace obfusquée est peu utile, puisque vous n’avez pas accès au nom de classe, au chemin du fichier et au numéro de ligne. Il est alors difficile d’identifier l’origine de l’erreur dans votre codebase. De plus, l’extrait de code est toujours minifié (il s’agit d’une longue ligne de code transformé), ce qui rend le processus de dépannage encore plus difficile. Voici un exemple de stack trace minifiée :

À l’inverse, une stack trace désobfusquée vous donne tout le contexte dont vous avez besoin pour dépanner le problème :

Pour aller plus loin
Documentation, liens et articles supplémentaires utiles: