La transition de la version 2 à la version 3 se concentre sur la suppression de la prise en charge du projet Open Tracing hérité, améliorant ainsi la stabilité et la cohérence du SDK.

La migration de la v2 vers la v3 se concentre sur la rationalisation des modules, l’affinement des valeurs par défaut et l’amélioration de la fiabilité des fonctionnalités du produit.

Tous les produits SDK (RUM, Trace, Logs, Session Replay, etc.) restent modulaires et séparés en bibliothèques distinctes. Le changement principal est que le module DatadogObjc a été supprimé, son contenu ayant été intégré aux modules de produit correspondants.

La migration de la v2 vers la v3 se concentre sur l’alignement de la configuration avec le comportement du SDK modulaire v3 et sur la consolidation de la propriété de la configuration entre CoreConfiguration, RumConfiguration, LogsConfiguration et TraceConfiguration.

Veuillez lire le guide MIGRATION.md dans le dépôt officiel React Native pour obtenir la liste complète des changements.

Prérequis :

• Kotlin 1.9 est requis
• La dépendance Open Tracing a été supprimée car elle est obsolète

Les bibliothèques continuent d’être modularisées dans la v3. Adoptez les bibliothèques suivantes :

• DatadogCore
• DatadogCrashReporting
• DatadogLogs
• DatadogRUM
• DatadogSessionReplay
• DatadogTrace
• DatadogWebViewTracking

let package = Package(
  ...
  dependencies: [
      .package(url: "https://github.com/DataDog/dd-sdk-ios", from: "3.0.0")
  ],
  targets: [
      .target(
          ...
          dependencies: [
              .product(name: "DatadogCore", package: "dd-sdk-ios"),
              .product(name: "DatadogCrashReporting", package: "dd-sdk-ios"),
              .product(name: "DatadogLogs", package: "dd-sdk-ios"),
              .product(name: "DatadogRUM", package: "dd-sdk-ios"),
              .product(name: "DatadogSessionReplay", package: "dd-sdk-ios"),
              .product(name: "DatadogTrace", package: "dd-sdk-ios"),
              .product(name: "DatadogWebViewTracking", package: "dd-sdk-ios"),
          ]
      ),
  ]
)

pod 'DatadogCore'
pod 'DatadogCrashReporting'
pod 'DatadogLogs'
pod 'DatadogRUM'
pod 'DatadogSessionReplay'
pod 'DatadogTrace'
pod 'DatadogWebViewTracking'

github "DataDog/dd-sdk-ios"

DatadogInternal.xcframework
DatadogCore.xcframework

DatadogCrashReporting.xcframework
DatadogLogs.xcframework
DatadogRUM.xcframework
DatadogSessionReplay.xcframework
DatadogTrace.xcframework
DatadogWebViewTracking.xcframework

Consultez le guide MIGRATION.md dans le dépôt officiel React Native pour connaître les étapes de mise à niveau recommandées et les mises à jour de dépendances requises.

Core

Modifications de l’API :

RUM

Nous avons apporté des améliorations mineures aux modules RUM. Ils ne nécessitent pas de changements importants dans votre code, mais il est utile de vérifier si vous pouvez refactoriser certains paramètres redondants.

L’URL fournie dans la méthode useCustomEndpoint doit être l’URL complète de l’endpoint (https://example.com/rum/upload), et non seulement le nom d’hôte :

Rum.enable(
  RumConfiguration.Builder(...)
      .useCustomEndpoint("https://example.com/rum/upload")
      .build()
)

Modifications de l’API :

Logs

Le produit Logs ne signale plus les erreurs fatales. Pour activer Error Tracking pour les plantages, Crash Reporting doit être activé conjointement avec RUM.

L’URL fournie dans la méthode useCustomEndpoint doit être l’URL complète de l’endpoint (https://example.com/logs/upload), et non seulement le nom d’hôte :

Logs.enable(
  LogsConfiguration.Builder()
      .useCustomEndpoint("https://example.com/logs/upload")
      .build()
)

Trace

L’URL fournie dans la méthode useCustomEndpoint doit être l’URL complète de l’endpoint (par ex. : https://example.com/trace/upload), et non seulement le nom d’hôte, c’est-à-dire :

Trace.enable(
  TraceConfiguration.Builder()
      .useCustomEndpoint(`https://example.com/trace/upload`)
      .build()
)

Le projet Open Tracing a été marqué comme archivé et n’est plus pris en charge. Les dépendances Open Tracing ont été supprimées du SDK v3.

Le SDK Datadog prend déjà en charge Open Telemetry, qui est la méthode recommandée pour utiliser l’API de fonctionnalité de traçage.

Notez que la bibliothèque de spécification Open Telemetry nécessite que le desugaring soit activé pour les projets avec un minSdk < 26.

Migration du traçage de Open Tracing vers Open Telemetry (recommandé)

1. Ajoutez la dépendance Open Telemetry à votre build.gradle.kts :

implementation(project("com.datadoghq:dd-sdk-android-trace-otel:x.x.x"))

2. Remplacez la configuration Open Tracing :

GlobalTracer.registerIfAbsent(
  AndroidTracer.Builder()
    .setService(BuildConfig.APPLICATION_ID)
    .build()
)

par la configuration Open Telemetry :

GlobalOpenTelemetry.set(
  DatadogOpenTelemetry(BuildConfig.APPLICATION_ID)
)

Pour accéder à l’objet traceur pour un traçage manuel (personnalisé), utilisez io.opentelemetry.api.GlobalOpenTelemetry.get() au lieu de io.opentracing.util.GlobalTracer.get(). Exemple :

val tracer: Tracer = GlobalOpenTelemetry
  .get()
  .getTracer("SampleApplicationTracer")

val span = tracer
  .spanBuilder("Executing operation")
  .startSpan()

// Code that should be instrumented

span.end()

Consultez la Open Telemetrydocumentation officielle pour plus de détails.

Migration du traçage de Open Tracing vers DatadogTracing (période de transition)

GlobalTracer.registerIfAbsent(
  AndroidTracer.Builder()
    .setService(BuildConfig.APPLICATION_ID)
    .build()
)

par la configuration DatadogTracing :

GlobalDatadogTracer.registerIfAbsent(
  DatadogTracing.newTracerBuilder()
    .build()
)

Pour un traçage manuel (personnalisé), utilisez com.datadog.android.trace.GlobalDatadogTracer.get() au lieu de io.opentracing.util.GlobalTracer.get() pour accéder à l’objet traceur. Exemple :

val tracer = GlobalDatadogTracer.get()

val span = tracer
  .buildSpan("Executing operation")
  .start()

// Code that should be instrumented

span.finish()

Consultez la documentation Datadog pour plus de détails.

Modifications de l’API :

Conseils de remplacement :

Instrumentation OkHttp

L’instrumentation OkHttp (com.datadoghq:dd-sdk-android-okhttp:x.x.x) ne nécessite pas la prise en charge du « desugaring ». Cependant, quelques actions de migration peuvent être nécessaires.

Modifications de l’API :

Session Replay

L’URL fournie dans la méthode useCustomEndpoint doit être l’URL complète de l’endpoint (par ex. : https://example.com/session_replay/upload), et non seulement le nom d’hôte, c’est-à-dire :

SessionReplay.enable(
  SessionReplayConfiguration.Builder(...)
      .useCustomEndpoint("https://example.com/session_replay/upload")
      .build()
)

Le SDK doit être initialisé le plus tôt possible dans le cycle de vie de l’application, spécifiquement dans le rappel application(_:didFinishLaunchingWithOptions:) de AppDelegate. Cela garantit une mesure précise de toutes les métriques, y compris la durée de démarrage de l’application. Pour les applications créées avec SwiftUI, utilisez @UIApplicationDelegateAdaptor pour accéder à AppDelegate.

import DatadogCore

Datadog.initialize(
    with: Datadog.Configuration(
        clientToken: "<client token>",
        env: "<environment>",
        service: "<service name>"
    ),
    trackingConsent: .granted
)

Remarque : L’initialisation du SDK ailleurs (par exemple plus tard lors du chargement de la vue) peut entraîner des données de télémétrie inexactes ou manquantes, en particulier concernant les performances de démarrage de l’application.

RUM

Les attributs au niveau de la vue RUM sont automatiquement propagés à tous les événements enfants associés, y compris les ressources, les actions utilisateur, les erreurs et les tâches longues. Cela garantit la cohérence des métadonnées entre les événements, facilitant ainsi le filtrage et la corrélation des données sur les tableaux de bord Datadog.

Pour gérer plus efficacement les attributs au niveau de la vue, de nouvelles API ont été ajoutées :

• Monitor.addViewAttribute(forKey:value:)
• Monitor.addViewAttributes(_:)
• Monitor.removeViewAttribute(forKey:)
• Monitor.removeViewAttributes(forKeys:)

Autres changements notables :

• Toutes les API RUM Objective-C sont incluses dans DatadogRUM. Le module DatadogObjc séparé n’est plus disponible.
• Les blocages d’application et les arrêts par le watchdog ne sont plus signalés depuis les extensions d’application ou les widgets.
• Une nouvelle propriété trackMemoryWarnings a été ajoutée à RUM.Configuration pour signaler les avertissements de mémoire en tant qu’erreurs RUM.

Modifications de l’API :

Logs

Le produit Logs ne signale plus les erreurs fatales. Pour activer Error Tracking pour les plantages, Crash Reporting doit être activé conjointement avec RUM.

De plus, toutes les Objective-C Logs APIs sont incluses dans DatadogLogs. Le module DatadogObjc séparé n’est plus disponible.

Trace

L’échantillonnage des traces est désormais déterministe lorsqu’il est utilisé avec RUM. Il utilise le RUM session.id pour garantir un échantillonnage cohérent.

Également :

• La configuration Trace.Configuration.URLSessionTracking.FirstPartyHostsTracing définit l’échantillonnage pour toutes les requêtes par défaut et le contexte de trace est injecté uniquement dans les requêtes échantillonnées.
• Toutes les Objective-C Trace APIs sont incluses dans DatadogTrace. Le module DatadogObjc séparé n’est plus disponible.

Remarque : Une configuration similaire existe dans RUM.Configuration.URLSessionTracking.FirstPartyHostsTracing.

Session Replay

Les paramètres de confidentialité sont plus granulaires. Le paramètre defaultPrivacyLevel précédent a été remplacé par :

• textAndInputPrivacyLevel
• imagePrivacyLevel
• touchPrivacyLevel

En savoir plus sur les niveaux de confidentialité.

Modifications de l’API :

URLSession Instrumentation

Pour activer l’instrumentation URLSession, assurez-vous également d’activer RUM et/ou Trace pour effectuer des rapports vers ces produits respectifs.

Les types de délégués hérités ont été remplacés par une API d’instrumentation unifiée :

Veuillez lire le guide MIGRATION.md dans le dépôt officiel React Native.

Modifications de configuration

Certaines propriétés de configuration ont été déplacées, renommées, supprimées ou divisées :

Structures renommées

Mises à jour de l’API

En plus des changements de propriété de configuration (configurations Core vs feature), plusieurs types publics et API ont été renommés ou déplacés pour correspondre à la conception modulaire de la v3. Consultez le guide MIGRATION.md pour obtenir la liste officielle et des exemples de code.

La migration de la v1 vers la v2 représente une migration d’un SDK monolithique vers une architecture modulaire. RUM, Trace, Logs, Session Replay, etc. possèdent chacun des modules individuels, vous permettant d’intégrer uniquement ce qui est nécessaire dans votre application.

Le SDK v2 offre une disposition d’API unifiée et un alignement des noms entre le SDK iOS, le SDK Android et les autres produits Datadog.

Le SDK v2 permet l’utilisation de Mobile Session Replay sur les applications Android et iOS.

La migration de la v1 vers la v2 représente une migration d’un SDK monolithique vers une architecture modulaire. RUM, Trace, Logs, Session Replay, etc. possèdent chacun des modules individuels, vous permettant d’intégrer uniquement ce qui est nécessaire dans votre application.

Le SDK v2 offre une disposition d’API unifiée et un alignement des noms entre le SDK iOS, le SDK Android et les autres produits Datadog.

Le SDK v2 permet l’utilisation de Mobile Session Replay sur les applications Android et iOS.

La migration vers la version 2 offre des performances supérieures par rapport à la version 1.

La migration vers la version 2 offre des performances supérieures par rapport à la version 1. De plus, les SDK Native v2 proposent des fonctionnalités supplémentaires.

Les artefacts sont modularisés dans la v2. Adoptez les artefacts suivants :

• RUM : com.datadoghq:dd-sdk-android-rum:x.x.x
• Logs : com.datadoghq:dd-sdk-android-logs:x.x.x
• Trace : com.datadoghq:dd-sdk-android-trace:x.x.x
• Session Replay : com.datadoghq:dd-sdk-android-session-replay:x.x.x
• WebView Tracking : com.datadoghq:dd-sdk-android-webview:x.x.x
• OkHttp instrumentation : com.datadoghq:dd-sdk-android-okhttp:x.x.x

Remarque : Si vous utilisez NDK Crash Reporting et WebView Tracking, vous devez ajouter les artefacts RUM et Logs pour signaler les événements à RUM et Logs respectivement.

La référence à l’artefact com.datadoghq:dd-sdk-android doit être supprimée de votre script de build Gradle, car cet artefact n’existe plus.

Remarque : Les coordonnées Maven de tous les autres artefacts restent les mêmes.

Si jamais vous rencontrez une erreur semblable à ce qui suit :

A failure occurred while executing com.android.build.gradle.internal.tasks.CheckDuplicatesRunnable
Duplicate class kotlin.collections.jdk8.CollectionsJDK8Kt found in modules kotlin-stdlib-1.8.10 (org.jetbrains.kotlin:kotlin-stdlib:1.8.10) and kotlin-stdlib-jdk8-1.7.20 (org.jetbrains.kotlin:kotlin-stdlib-jdk8:1.7.20)

Ajoutez les règles suivantes à votre script de build (plus de détails dans le problème Stack Overflow correspondant) :

dependencies {
    constraints {
        implementation("org.jetbrains.kotlin:kotlin-stdlib-jdk7:1.8.10") {
            because("kotlin-stdlib-jdk7 is now a part of kotlin-stdlib")
        }
        implementation("org.jetbrains.kotlin:kotlin-stdlib-jdk8:1.8.10") {
            because("kotlin-stdlib-jdk8 is now a part of kotlin-stdlib")
        }
    }
}

Consultez l’exemple d’application Android pour savoir comment configurer le SDK.

Les bibliothèques sont modularisées dans la v2. Adoptez les bibliothèques suivantes :

• DatadogCore
• DatadogLogs
• DatadogTrace
• DatadogSessionReplay
• DatadogRUM
• DatadogWebViewTracking

Celles-ci s’ajoutent aux DatadogCrashReporting et DatadogObjc existantes.

let package = Package(
  ...
  dependencies: [
      .package(url: "https://github.com/DataDog/dd-sdk-ios", from: "2.0.0")
  ],
  targets: [
      .target(
          ...
          dependencies: [
              .product(name: "DatadogCore", package: "dd-sdk-ios"),
              .product(name: "DatadogLogs", package: "dd-sdk-ios"),
              .product(name: "DatadogTrace", package: "dd-sdk-ios"),
              .product(name: "DatadogSessionReplay", package: "dd-sdk-ios"),
              .product(name: "DatadogRUM", package: "dd-sdk-ios"),
              .product(name: "DatadogCrashReporting", package: "dd-sdk-ios"),
              .product(name: "DatadogWebViewTracking", package: "dd-sdk-ios"),
          ]
      ),
  ]
)

pod 'DatadogCore'
pod 'DatadogLogs'
pod 'DatadogTrace'
pod 'DatadogSessionReplay'
pod 'DatadogRUM'
pod 'DatadogCrashReporting'
pod 'DatadogWebViewTracking'
pod 'DatadogObjc'

github "DataDog/dd-sdk-ios"

DatadogInternal.xcframework
DatadogCore.xcframework

DatadogLogs.xcframework
DatadogTrace.xcframework
DatadogSessionReplay.xcframework
DatadogRUM.xcframework
DatadogCrashReporting.xcframework + CrashReporter.xcframework
DatadogWebViewTracking.xcframework
DatadogObjc.xcframework

Remarque : Lorsque vous utilisez Crash Reporting et WebView Tracking, vous devez ajouter les modules RUM et Logs pour signaler les événements à RUM et Logs respectivement.

Mettez à jour @datadog/mobile-react-native dans votre package.json :

"@datadog/mobile-react-native": "2.0.0"

Mettez à jour vos pods iOS :

(cd ios && bundle exec pod update)

Si vous utilisez une version de React Native strictement supérieure à 0.67, utilisez la version 17 de Java. Si vous utilisez une version de React Native égale ou inférieure à 0.67, utilisez la version 11 de Java. Pour vérifier votre version de Java, exécutez la commande suivante dans un terminal :

java --version

Pour React Native < 0.73

Dans votre fichier android/build.gradle, spécifiez kotlinVersion pour éviter les conflits entre les dépendances Kotlin :

buildscript {
    ext {
        // targetSdkVersion = ...
        kotlinVersion = "1.8.21"
    }
}

Pour React Native < 0.68

Dans votre fichier android/build.gradle, spécifiez kotlinVersion pour éviter les conflits entre les dépendances Kotlin :

buildscript {
    ext {
        // targetSdkVersion = ...
        kotlinVersion = "1.8.21"
    }
}

Si vous utilisez une version de com.android.tools.build:gradle inférieure à 5.0 dans votre android/build.gradle, ajoutez dans votre fichier android/gradle.properties :

android.jetifier.ignorelist=dd-sdk-android-core

Dépannage

Le build Android échoue avec Unable to make field private final java.lang.String java.io.File.path accessible

Si votre build Android échoue avec une erreur telle que :

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':app:processReleaseMainManifest'.
> Unable to make field private final java.lang.String java.io.File.path accessible: module java.base does not "opens java.io" to unnamed module @1bbf7f0e

Vous utilisez Java 17, qui n’est pas compatible avec votre version de React Native. Passez à Java 11 pour résoudre le problème.

La compilation Android échoue avec Unsupported class file major version 61

Si votre build Android échoue avec une erreur telle que :

FAILURE: Build failed with an exception.

* What went wrong:
Could not determine the dependencies of task ':app:lintVitalRelease'.
> Could not resolve all artifacts for configuration ':app:debugRuntimeClasspath'.
   > Failed to transform dd-sdk-android-core-2.0.0.aar (com.datadoghq:dd-sdk-android-core:2.0.0) to match attributes {artifactType=android-manifest, org.gradle.category=library, org.gradle.dependency.bundling=external, org.gradle.libraryelements=aar, org.gradle.status=release, org.gradle.usage=java-runtime}.
      > Execution failed for JetifyTransform: /Users/me/.gradle/caches/modules-2/files-2.1/com.datadoghq/dd-sdk-android-core/2.0.0/a97f8a1537da1de99a86adf32c307198b477971f/dd-sdk-android-core-2.0.0.aar.
         > Failed to transform '/Users/me/.gradle/caches/modules-2/files-2.1/com.datadoghq/dd-sdk-android-core/2.0.0/a97f8a1537da1de99a86adf32c307198b477971f/dd-sdk-android-core-2.0.0.aar' using Jetifier. Reason: IllegalArgumentException, message: Unsupported class file major version 61. (Run with --stacktrace for more details.)

Vous utilisez une version du plugin Android Gradle inférieure à 5.0. Pour résoudre le problème, ajoutez dans votre fichier android/gradle.properties :

android.jetifier.ignorelist=dd-sdk-android-core

La compilation Android échoue avec Duplicate class kotlin.collections.jdk8.*

Si votre build Android échoue avec une erreur telle que :

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':app:checkReleaseDuplicateClasses'.
> A failure occurred while executing com.android.build.gradle.internal.tasks.CheckDuplicatesRunnable
   > Duplicate class kotlin.collections.jdk8.CollectionsJDK8Kt found in modules jetified-kotlin-stdlib-1.8.10 (org.jetbrains.kotlin:kotlin-stdlib:1.8.10) and jetified-kotlin-stdlib-jdk8-1.7.20 (org.jetbrains.kotlin:kotlin-stdlib-jdk8:1.7.20)
     Duplicate class kotlin.internal.jdk7.JDK7PlatformImplementations found in modules jetified-kotlin-stdlib-1.8.10 (org.jetbrains.kotlin:kotlin-stdlib:1.8.10) and jetified-kotlin-stdlib-jdk7-1.7.20 (org.jetbrains.kotlin:kotlin-stdlib-jdk7:1.7.20)

Vous devez définir une version de Kotlin pour votre projet afin d’éviter les conflits entre les dépendances Kotlin. Dans votre fichier android/build.gradle, spécifiez le kotlinVersion :

buildscript {
    ext {
        // targetSdkVersion = ...
        kotlinVersion = "1.8.21"
    }
}

Alternativement, vous pouvez ajouter les règles suivantes à votre script de compilation dans votre fichier android/app/build.gradle :

dependencies {
    constraints {
        implementation("org.jetbrains.kotlin:kotlin-stdlib-jdk7:1.8.10") {
            because("kotlin-stdlib-jdk7 is now a part of kotlin-stdlib")
        }
        implementation("org.jetbrains.kotlin:kotlin-stdlib-jdk8:1.8.10") {
            because("kotlin-stdlib-jdk8 is now a part of kotlin-stdlib")
        }
    }
}

Mettez à jour datadog_flutter_plugin dans votre pubspec.yaml :

dependencies:
  'datadog_flutter_plugin: ^2.0.0

Dépannage

Interface en double (iOS)

Si vous voyez cette erreur lors de la compilation iOS après la mise à niveau vers datadog_flutter_plugin v2.0 :

Semantic Issue (Xcode): Duplicate interface definition for class 'DatadogSdkPlugin'
/Users/exampleuser/Projects/test_app/build/ios/Debug-iphonesimulator/datadog_flutter_plugin/datadog_flutter_plugin.framework/Headers/DatadogSdkPlugin.h:6:0

Essayez d’effectuer flutter clean && flutter pub get et de recompiler. Cela résout généralement le problème.

Classes dupliquées (Android)

Si vous voyez cette erreur lors de la compilation d’Android après la mise à niveau vers datadog_flutter_plugin v2.0 :

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':app:checkDebugDuplicateClasses'.
> A failure occurred while executing com.android.build.gradle.internal.tasks.CheckDuplicatesRunnable

Assurez-vous d’avoir mis à jour votre version de Kotlin vers au moins 1.8 dans votre fichier build.gradle.

Avec l’extraction de différents produits dans des modules indépendants, la configuration du SDK est organisée par module.

com.datadog.android.core.configuration.Configuration.Builder La classe présente les changements suivants :

• Le jeton client, le nom de l’environnement, le nom de la variante (la valeur par défaut est une chaîne vide) et le nom du service (la valeur par défaut est l’ID d’application extrait du manifeste) doivent être fournis dans le constructeur.
• La classe com.datadog.android.core.configuration.Credentials est supprimée.
• logsEnabled, tracesEnabled et rumEnabled sont supprimés du constructeur au profit d’une configuration de produit individuelle (voir ci-dessous).
• crashReportsEnabled L’argument du constructeur est supprimé. Vous pouvez activer ou désactiver le rapport de plantage JVM avec la méthode Configuration.Builder.setCrashReportsEnabled. Par défaut, le rapport de plantage JVM est activé.
• Les méthodes de configuration des produits RUM, Logs et Trace sont supprimées de Configuration.Builder au profit de la configuration de produit individuelle (voir ci-dessous).

La méthode Datadog.initialize n’inclut plus la classe Credentials dans la liste des arguments.

Le package com.datadog.android.plugin et toutes les classes/méthodes associées sont supprimés.

Logs

Toutes les classes liées au produit Logs sont strictement contenues dans le package com.datadog.android.log.

Pour utiliser la fonctionnalité de logs, importez l’artefact suivant :

implementation("com.datadoghq:dd-sdk-android-logs:x.x.x")

Vous pouvez activer le produit Logs avec l’extrait suivant :

val logsConfig = LogsConfiguration.Builder()
    ...
    .build()

Logs.enable(logsConfig)

val logger = Logger.Builder()
    ...
    .build()

Modifications de l’API :

Trace

Toutes les classes liées au produit Trace sont strictement contenues dans le package com.datadog.android.trace (cela signifie que toutes les classes résidant auparavant dans com.datadog.android.tracing ont été déplacées).

Pour utiliser le produit Trace, importez l’artefact suivant :

implementation("com.datadoghq:dd-sdk-android-trace:x.x.x")

Vous pouvez activer le produit Trace avec l’extrait suivant :

val traceConfig = TraceConfiguration.Builder()
    ...
    .build()

Trace.enable(traceConfig)

val tracer = AndroidTracer.Builder()
    ...
    .build()

GlobalTracer.registerIfAbsent(tracer)

Modifications de l’API :

RUM

Toutes les classes liées au produit RUM sont strictement contenues dans le package com.datadog.android.rum.

Pour utiliser le produit RUM, importez l’artefact suivant :

implementation("com.datadoghq:dd-sdk-android-rum:x.x.x")

Vous pouvez utiliser l’extrait de code suivant pour activer la solution RUM :

val rumConfig = RumConfiguration.Builder(rumApplicationId)
    ...
    .build()

Rum.enable(rumConfig)

Modifications de l’API :

Rapport de crash NDK

Le nom de l’artefact reste le même qu’auparavant : com.datadoghq:dd-sdk-android-ndk:x.x.x.

Vous pouvez activer le rapport de crash NDK avec l’extrait suivant :

NdkCrashReports.enable()

Cette configuration remplace l’appel com.datadog.android.core.configuration.Configuration.Builder.addPlugin.

Note : Vous devez avoir activé les produits RUM et Logs pour recevoir les rapports de crash NDK dans RUM et Logs respectivement.

Suivi WebView

Le nom de l’artefact reste le même qu’auparavant : com.datadoghq:dd-sdk-android-webview:x.x.x

Vous pouvez activer le suivi WebView avec l’extrait suivant :

WebViewTracking.enable(webView, allowedHosts)

Note : Vous devez avoir activé les produits RUM et Logs pour recevoir les événements provenant de WebView dans RUM et Logs respectivement.

Modifications de l’API :

Suivi OkHttp

Pour utiliser le suivi OkHttp, importez l’artefact suivant :

implementation("com.datadoghq:dd-sdk-android-okhttp:x.x.x")

L’instrumentation OkHttp prend en charge l’initialisation du SDK Datadog après le client OkHttp, ce qui vous permet de créer com.datadog.android.okhttp.DatadogEventListener, com.datadog.android.okhttp.DatadogInterceptor et com.datadog.android.okhttp.trace.TracingInterceptor avant d’initialiser le SDK Datadog. L’instrumentation OkHttp commence à signaler les événements à Datadog une fois que le SDK Datadog est initialisé.

com.datadog.android.okhttp.DatadogInterceptor et com.datadog.android.okhttp.trace.TracingInterceptor vous permettent tous deux de contrôler l’échantillonnage de manière dynamique grâce à l’intégration avec un système de configuration à distance.

Pour ajuster dynamiquement l’échantillonnage, fournissez votre propre implémentation de l’interface com.datadog.android.core.sampling.Sampler dans le constructeur com.datadog.android.okhttp.DatadogInterceptor/com.datadog.android.okhttp.trace.TracingInterceptor. Il est interrogé pour chaque requête afin de prendre la décision d’échantillonnage.

dd-sdk-android-ktx suppression du module

Pour améliorer la granularité des SDK Datadog utilisés, le module dd-sdk-android-ktx est supprimé. Le code est réparti entre les autres modules pour fournir des méthodes d’extension pour les fonctionnalités RUM et Trace.

Session Replay

Pour obtenir des instructions sur la configuration de Mobile Session Replay, consultez Mobile Session Replay Setup and Configuration.

Avec l’extraction de différents produits dans des modules indépendants, la configuration du SDK est organisée par module.

Le SDK doit être initialisé avant d’activer tout produit.

Le modèle Builder de l’initialisation du SDK a été supprimé au profit de définitions de structures. L’exemple suivant montre comment une initialisation 1.x se traduirait en 2.0.

Initialisation V1

import Datadog

Datadog.initialize(
    appContext: .init(),
    trackingConsent: .granted,
    configuration: Datadog.Configuration
        .builderUsing(
            clientToken: "<client token>",
            environment: "<environment>"
        )
        .set(serviceName: "<service name>")
        .build()

Initialisation V2

import DatadogCore

Datadog.initialize(
    with: Datadog.Configuration(
        clientToken: "<client token>",
        env: "<environment>",
        service: "<service name>"
    ),
    trackingConsent: .granted
)

Modifications de l’API :

Logs

Toutes les classes liées aux Logs se trouvent strictement dans le module DatadogLogs. Vous devez d’abord activer le produit :

import DatadogLogs

Logs.enable(with: Logs.Configuration(...))

Vous pouvez ensuite créer votre instance de logger :

import DatadogLogs

let logger = Logger.create(
    with: Logger.Configuration(name: "<logger name>")
)

Modifications de l’API :

Trace

Toutes les classes liées à Trace se trouvent strictement dans le module DatadogTrace. Vous devez d’abord activer le produit :

import DatadogTrace

Trace.enable(
    with: Trace.Configuration(...)
)

Ensuite, vous pouvez accéder à l’instance partagée du Tracer :

import DatadogTrace

let tracer = Tracer.shared()

Modifications de l’API :

RUM

Toutes les classes liées à RUM se trouvent strictement dans le module DatadogRUM. Vous devez d’abord activer le produit :

import DatadogRUM

RUM.enable(
    with: RUM.Configuration(applicationID: "<RUM Application ID>")
)

Ensuite, vous pouvez accéder à l’instance partagée du monitor RUM :

import DatadogRUM

let monitor = RUMMonitor.shared()

Modifications de l’API :

Rapports de crash

Pour activer les rapports de crash, assurez-vous d’activer RUM et les Logs pour qu’ils rapportent respectivement à ces produits.

import DatadogCrashReporting

CrashReporting.enable()

Suivi WebView

Pour activer le suivi WebView, assurez-vous également d’activer RUM et les Logs pour qu’ils rapportent respectivement à ces produits.

import WebKit
import DatadogWebViewTracking

let webView = WKWebView(...)
WebViewTracking.enable(webView: webView)

Session Replay

Pour obtenir des instructions sur la configuration de Mobile Session Replay, consultez Mobile Session Replay Setup and Configuration.

Aucun changement dans l’initialisation du SDK n’est nécessaire.

Modifications de la configuration du SDK

Certaines propriétés de configuration ont été déplacées ou renommées, afin de prendre en charge la modularité dans les SDK natifs de Datadog.

Les structures suivantes ont été renommées :

Les propriétés suivantes ont été modifiées :

De plus, les API suivantes ont été modifiées :

Modifications de Flutter Web

Les clients utilisant Flutter Web doivent passer au SDK Datadog Browser v5. Modifiez l’importation suivante dans votre index.html :

-  <script type="text/javascript" src="https://www.datadoghq-browser-agent.com/datadog-logs-v4.js"></script>
-  <script type="text/javascript" src="https://www.datadoghq-browser-agent.com/datadog-rum-slim-v4.js"></script>
+  <script type="text/javascript" src="https://www.datadoghq-browser-agent.com/us1/v5/datadog-logs.js"></script>
+  <script type="text/javascript" src="https://www.datadoghq-browser-agent.com/us1/v5/datadog-rum-slim.js"></script>

Remarque : Datadog fournit un bundle CDN par site. Consultez le README du SDK Browser pour obtenir la liste de toutes les URL de site.

Modifications du produit Logs

Comme pour la v1, la journalisation Datadog peut être activée en définissant le membre DatadogConfiguration.loggingConfiguration. Cependant, contrairement à la v1, Datadog ne crée pas de logger par défaut pour vous. DatadogSdk.logs est désormais une instance de DatadogLogging, qui peut être utilisée pour créer des logs. De nombreuses options ont été déplacées vers DatadogLoggerConfiguration pour offrir aux développeurs un contrôle plus granulaire sur les loggers individuels.

Les API suivantes ont été modifiées :

Modifications du produit RUM

Les API suivantes ont été modifiées :

De plus, les mappeurs d’événements ne vous permettent plus de modifier leurs noms de vue. Pour renommer une vue, utilisez plutôt un ViewInfoExtractor personnalisé.