Standardize mobile crash report setup

content/en/real_user_monitoring/error_tracking/mobile/android.md

@@ -39,7 +39,9 @@ If you have not set up the Android SDK yet, follow the [in-app setup instruction
 
 For any given error, you can access the file path, line number, and a code snippet for each frame of the related stack trace.
 
-## Upload your mapping file
+## Get deobfuscated stack traces
+
+### Upload your mapping file
 
 **Note**: Re-uploading a source map does not override the existing one if the version has not changed.
 
@@ -157,7 +159,7 @@ For example:
 tasks["minify${variant}WithR8"].finalizedBy { tasks["uploadMapping${variant}"] }
 ```
 
-### Limitations
+## Limitations
 
 {{< site-region region="us,us3,us5,eu,gov" >}}
 Mapping files are limited to **500** MB. If your project has a mapping file larger than this, use one of the following options to reduce the file size:
@@ -181,6 +183,23 @@ datadog {
 }
 ```
 
+## Test your implementation
+
+To verify your Android Crash Reporting and Error Tracking configuration, you need to trigger a crash in your RUM application and confirm that the error appears in Datadog.
+
+To test your implementation:
+
+1. Run your application on an Android emulator or a real device.
+2. Execute some code containing an error or crash. For example:
+
+   ```kotlin
+   fun onEvent() {
+       throw RuntimeException("Crash the app")
+   }
+   ```
+
+3. After the crash happens, restart your application and wait for the Android SDK to upload the crash report in [**Error Tracking**][1].
+
 ## Further Reading
 
 {{< partial name="whats-next/whats-next.html" >}}

content/en/real_user_monitoring/error_tracking/mobile/expo.md

@@ -54,18 +54,6 @@ yarn add -D @datadog/datadog-ci
 
 Run `eas secret:create` to set `DATADOG_API_KEY` to your Datadog API key.
 
-### Add git repository data to your mapping files on Expo Application Services (EAS)
-
-If you are using EAS to build your Expo application, set `cli.requireCommit` to `true` in your `eas.json` file to add git repository data to your mapping files.
-
-```json
-{
-    "cli": {
-        "requireCommit": true
-    }
-}
-```
-
 ### Setting the Datadog site
 
 Run `eas secret:create` to set `DATADOG_SITE` to the host of your Datadog site, for example: `datadoghq.eu`. By default, `datadoghq.com` is used.
@@ -80,15 +68,33 @@ Run `eas secret:create` to set `DATADOG_SITE` to the host of your Datadog site,
 | `androidProguardMappingFiles` | `true`  | Enables the uploading of Proguard mapping files to deobfuscate native Android crashes (is only applied if obfuscation is enabled). |
 | `datadogGradlePluginVersion`  | `"1.+"` | Version of `dd-sdk-android-gradle-plugin` used for uploading Proguard mapping files.     |
 
-### Limitations
+## Get deobfuscated stack traces
+
+### Add git repository data to your mapping files on Expo Application Services (EAS)
+
+If you are using EAS to build your Expo application, set `cli.requireCommit` to `true` in your `eas.json` file to add git repository data to your mapping files.
+
+```json
+{
+    "cli": {
+        "requireCommit": true
+    }
+}
+```
+
+## Limitations
 
 {{< site-region region="us,us3,us5,eu,gov" >}}
 Source maps, mapping files, and dSYM files are limited to **500** MB each.
 {{< /site-region >}}
 {{< site-region region="ap1" >}}
-Source maps, mapping files, and dSYM files  are limited to **500** MB each.
+Source maps, mapping files, and dSYM files are limited to **500** MB each.
 {{< /site-region >}}
 
+## Test your implementation
+
+## Additional configuration options
+
 ### Disable file uploads
 
 You can disable some files from uploading by setting the `iosDsyms`, `iosSourcemaps`, `androidProguardMappingFiles`, or `androidSourcemaps` parameters to `false`.
@@ -113,7 +119,7 @@ You can disable some files from uploading by setting the `iosDsyms`, `iosSourcem
 If you want to disable **all file uploads**, remove `expo-datadog` from the list of plugins.
 
 
-### Using with Sentry
+### Using Expo with Datadog and Sentry
 
 Both Datadog and Sentry config plugins use regular expressions to modify the "Bundle React Native code and images" iOS build phase to send the sourcemap. This can make your EAS builds fail with a `error: Found argument 'datadog-ci' which wasn't expected, or isn't valid in this context` error.
 

content/en/real_user_monitoring/error_tracking/mobile/flutter.md

@@ -27,6 +27,29 @@ Your crash reports appear in [**Error Tracking**][1].
 
 If you have not set up the Datadog Flutter SDK for RUM yet, follow the [in-app setup instructions][2] or see the [Flutter setup documentation][3].
 
+### Add Dart error tracking
+
+If you are using `DatadogSdk.runApp`, then the Datadog Flutter SDK automatically tracks and reports uncaught Dart exceptions.
+
+If you are **not** using `DatadogSdk.runApp`, you need to setup Dart error tracking manually with the following code before you initialize Datadog:
+
+```dart
+final originalOnError = FlutterError.onError;
+FlutterError.onError = (details) {
+  DatadogSdk.instance.rum?.handleFlutterError(details);
+  originalOnError?.call(details);
+};
+final platformOriginalOnError = PlatformDispatcher.instance.onError;
+PlatformDispatcher.instance.onError = (e, st) {
+  DatadogSdk.instance.rum?.addErrorInfo(
+    e.toString(),
+    RumErrorSource.source,
+    stackTrace: st,
+  );
+  return platformOriginalOnError?.call(e, st) ?? false;
+};
+```
+
 ### Add native crash reporting
 
 Update your initialization snippet to enable native crash reporting for iOS and Android by setting `nativeCrashReportEnabled` to `true`.
@@ -44,17 +67,19 @@ final configuration = DatadogConfiguration(
     applicationId: '<DD_APP_ID>',
   ),
 );
-DatadogSdk.instance.initialize(configuration);
 ```
 
-If your application suffers a fatal crash, after your application restarts, the Datadog Flutter SDK uploads a crash report to Datadog. For non-fatal errors, the Datadog Flutter SDK uploads these errors with other RUM data.
+If your application suffers a fatal crash, the Datadog Flutter SDK uploads a crash report to Datadog *after* your application restarts. For non-fatal errors, the Datadog Flutter SDK uploads these errors with other RUM data.
 
-## Upload symbol files to Datadog
+## Get deobfuscated stack traces
+
+### Upload symbol files to Datadog
 
 Native iOS crash reports are collected in a raw format and mostly contain memory addresses. To map these addresses into legible symbol information, Datadog requires that you upload .dSYM files, which are generated in your application's build process.
 
-For all crash reports that are built with the `--split-debug-info` option set and/or with the `--obfuscate` option set, you need to upload their Android Proguard mapping file and Dart symbol files generated by the Flutter build process.
+Crash reports and errors sent from Flutter iOS and Android applications that are built with the `--split-debug-info` option set and/or with the `--obfuscate` option set will also be in a raw or obfuscated format. For these applications, you need to upload their Android Proguard mapping file and Dart symbol files generated by the Flutter build process.
 
+Errors sent from Flutter Web applications will send unmapped JavaScript file and line numbers, which need to be mapped to Dart file and line numbers. For these applications, you need to upload the Flutter generated JavaScript source map generated by the Flutter build porcess.
 
 The [@datadog/datadog-ci][4] command line tool supports uploading all of the necessary files (dSYMs, Android Proguard Mapping, and Dart Symbol Files) in one command.
 
@@ -79,7 +104,7 @@ datadog-ci flutter-symbols upload --service-name <your_service_name> --dart-symb
 
 For a full list of options, see the `datadog-ci` [Flutter Symbols documentation][5].
 
-### Limitations
+## Limitations
 
 {{< site-region region="us,us3,us5,eu,gov" >}}
 Source maps and dSYM files are limited to **500** MB each.
@@ -88,23 +113,39 @@ Source maps and dSYM files are limited to **500** MB each.
 Source maps and dSYM files are limited to **500** MB each.
 {{< /site-region >}}
 
-## Advanced Configuration - Flavors and Build Numbers
+## Test your implementation
+
+To verify your Flutter Crash Reporting and Error Tracking configuration, issue an error in your RUM application and confirm that the error appears in Datadog.
+
+1. Run your application on a simulator, emulator, or a real device. If you are running on iOS, ensure that the debugger is not attached. Otherwise, Xcode captures the crash before the Datadog SDK does.
+2. Execute code containing an error or crash. For example:
+
+   ```dart
+   void throwError() {
+    throw Exception("My Exception")
+   }
+   ```
+
+3. For obfuscated error reports that do not result in a crash, you can verify symbolication and deobfuscation in [**Error Tracking**][8].
+4. For crashes, after the crash happens, restart your application and wait for the Flutter SDK to upload the crash report in [**Error Tracking**][8].
+
+### Flavors and build numbers
 
 Datadog uses the combination of the `service-name`, `version`, and `flavor` to locate the correct symbols for deobfuscation. For your crash reports to have complete information, the parameters sent to the `datadog-ci` command and the parameters set in [DatadogConfiguration][6] must match exactly.
 
-If you are using app [flavors][7] in Flutter, you will need to set the name of the flavor in [DatadogConfiguration.flavor][8] since we cannot detect the flavor automatically. You can then pass this to the `--flavor` parameter of the `datadog-ci` command:
+If you are using app [flavors][7] in Flutter, you need to set the name of the flavor in [DatadogConfiguration.flavor][8] since we cannot detect the flavor automatically. You can then pass this to the `--flavor` parameter of the `datadog-ci` command:
 
 ```sh
 datadog-ci flutter-symbols upload --service-name <your_service_name> --dart-symbols-location <location_of_dart_symbols> --android-mapping --ios-dsyms --flavor my_flavor
 ```
 
-The Datadog SDK will automatically detect the version number of your application specified in your `pubspec.yaml` up to but not including the build number. If you are using build numbers as part of the version in your application and need to upload symbols for each build, you will need to add the version to [DatadogConfiguration.version][9]. You can then pass this to the `--version` parameter of the `datadog-ci` command:
+The Datadog SDK automatically detects the version number of your application specified in your `pubspec.yaml` up to but not including the build number. If you are using build numbers as part of the version in your application and need to upload symbols for each build, you need to add the version to [DatadogConfiguration.version][9]. You can then pass this to the `--version` parameter of the `datadog-ci` command:
 
 ```sh
 datadog-ci flutter-symbols upload --service-name <your_service_name> --dart-symbols-location <location_of_dart_symbols> --android-mapping --ios-dsyms --version 1.2.3+22
 ```
 
-Note that Datadog uses tags for versions which do not allow `+`. All tooling automatically replaces `+` with `-` so that the version tags are searchable in Datadog.
+**Note**: Datadog uses tags for versions which do not allow `+`. All tooling automatically replaces `+` with `-` so that the version tags are searchable in Datadog.
 
 ## Further reading
 

content/en/real_user_monitoring/error_tracking/mobile/ios.md

@@ -100,13 +100,15 @@ Datadog.initialize(
 CrashReporting.enable()
 ```
 
-## Symbolicate crash reports
+## Get deobfuscated stack traces
+
+### Symbolicate crash reports
 
 Crash reports are collected in a raw format and mostly contain memory addresses. To map these addresses into legible symbol information, Datadog requires .dSYM files, which are generated in your application's build or distribution process.
 
-### Find your dSYM file
+### Find your .dSYM file
 
-Every iOS application produces .dSYM files for each application module. These files minimize an application's binary size and enable faster download speed. Each application version contains a set of .dSYM files. 
+Every iOS application produces `.dSYM` files for each application module. These files minimize an application's binary size and enable faster download speed. Each application version contains a set of `.dSYM` files. 
 
 Depending on your setup, you may need to download `.dSYM` files from App Store Connect or find them on your local machine. 
 
@@ -115,17 +117,17 @@ Depending on your setup, you may need to download `.dSYM` files from App Store C
 | Yes | `.dSYM` files are available after [App Store Connect][6] completes processing your application's build. |
 | No | Xcode exports `.dSYM` files to `$DWARF_DSYM_FOLDER_PATH` at the end of your application's build. Ensure that the `DEBUG_INFORMATION_FORMAT` build setting is set to **DWARF with dSYM File**. By default, Xcode projects only set `DEBUG_INFORMATION_FORMAT` to **DWARF with dSYM File** for the Release project configuration. |
 
-### Upload your dSYM file
+### Upload your .dSYM file
 
-By uploading your .dSYM file to Datadog, you gain access to the file path and line number of each frame in an error's related stack trace.
+By uploading your `.dSYM` file to Datadog, you gain access to the file path and line number of each frame in an error's related stack trace.
 
 Once your application crashes and you restart the application, the iOS SDK uploads a crash report to Datadog.
 
 **Note**: Re-uploading a source map does not override the existing one if the version has not changed.
 
-#### Datadog CI
+### Use Datadog CI to upload your .dSYM file
 
-You can use the command line tool [@datadog/datadog-ci][5] to upload your dSYM file:
+You can use the command line tool [@datadog/datadog-ci][5] to upload your `.dSYM` file:
 
 ```sh
 export DATADOG_API_KEY="<API KEY>"
@@ -141,9 +143,9 @@ npx @datadog/datadog-ci dsyms upload /path/to/appDsyms/
 
 Alternatively, if you use Fastlane or GitHub Actions in your workflows, you can leverage these integrations instead of `datadog-ci`:
 
-#### Fastlane Plugin
+### Use Fastlane plugin to upload your .dSYM file
 
-The Datadog plugin helps you upload dSYM files to Datadog from your Fastlane configuration.
+The Fastlane plugin helps you upload `.dSYM` files to Datadog from your Fastlane configuration.
 
 1. Add [`fastlane-plugin-datadog`][3] to your project.
 
@@ -163,7 +165,7 @@ The Datadog plugin helps you upload dSYM files to Datadog from your Fastlane con
 
 For more information, see [`fastlane-plugin-datadog`][3].
 
-#### GitHub Action
+### Use GitHub Actions to upload your .dSYM file
 
 The [Datadog Upload dSYMs GitHub Action][4] allows you to upload your symbols in your GitHub Action jobs:
 
@@ -193,7 +195,7 @@ jobs:
 
 For more information, see [dSYMs commands][7].
 
-### Limitations
+## Limitations
 
 {{< site-region region="us,us3,us5,eu,gov" >}}
 dSYM files are limited to **500** MB.
@@ -202,7 +204,7 @@ dSYM files are limited to **500** MB.
 dSYM files are limited to **500** MB.
 {{< /site-region >}}
 
-## Verify crash reports
+## Test your implementation
 
 To verify your iOS Crash Reporting and Error Tracking configuration, issue a crash in your RUM application and confirm that the error appears in Datadog.