Prototype: Sentry docs top nav restructure

docs/platforms/android/data-management/data-collected.mdx

@@ -12,7 +12,7 @@ Many of the categories listed here require you to enable the <PlatformLink to="/
 
 ## HTTP Headers
 
-By default, the Sentry SDK doesn't send any HTTP headers. Even when sending HTTP headers is enabled, we have a [denylist](https://github.com/getsentry/sentry-java/blob/main/sentry/src/main/java/io/sentry/util/HttpUtils.java#L21-L34) in place, which filters out any headers that contain sensitive data.
+By default, the Sentry SDK doesn't send any headers for outgoing HTTP request. Even when sending HTTP headers is enabled, we have a [denylist](https://github.com/getsentry/sentry-java/blob/main/sentry/src/main/java/io/sentry/util/HttpUtils.java#L21-L34) in place, which filters out any headers that contain sensitive data.
 
 To start sending HTTP headers, set <PlatformLink to="/configuration/options/#send-default-pii">`sendDefaultPii=true`</PlatformLink>.
 

docs/platforms/android/index.mdx

@@ -110,23 +110,29 @@ The wizard will prompt you to log in to Sentry. It'll then automatically do the
 Configuration is done via the application `AndroidManifest.xml`. Here's an example config which should get you started:
 
 
-```xml {filename:AndroidManifest.xml} {"onboardingOptions": {"performance": "6-7", "profiling": "8-13", "session-replay": "14-16"}}
+```xml {filename:AndroidManifest.xml}
 <application>
   <!-- Required: set your sentry.io project identifier (DSN) -->
   <meta-data android:name="io.sentry.dsn" android:value="___PUBLIC_DSN___" />
   <!-- Add data like request headers, user ip address and device name, see https://docs.sentry.io/platforms/android/data-management/data-collected/ for more info -->
   <meta-data android:name="io.sentry.send-default-pii" android:value="true" />
+  <!-- ___PRODUCT_OPTION_START___ performance -->
   <!-- Enable the performance API by setting a sample-rate, adjust in production env -->
   <meta-data android:name="io.sentry.traces.sample-rate" android:value="1.0" />
+  <!-- ___PRODUCT_OPTION_END___ performance -->
+  <!-- ___PRODUCT_OPTION_START___ profiling -->
   <!-- Enable profiling, adjust in production env. This is evaluated only once per session -->
   <meta-data android:name="io.sentry.traces.profiling.session-sample-rate" android:value="1.0" />
   <!-- Set profiling lifecycle, can be `manual` (controlled through `Sentry.startProfiler()` and `Sentry.stopProfiler()`) or `trace` (automatically starts and stop a profile whenever a sampled trace starts and finishes) -->
   <meta-data android:name="io.sentry.traces.profiling.lifecycle" android:value="trace" />
   <!-- Enable profiling on app start -->
   <meta-data android:name="io.sentry.traces.profiling.start-on-app-start" android:value="true" />
+  <!-- ___PRODUCT_OPTION_END___ profiling -->
+  <!-- ___PRODUCT_OPTION_START___ session-replay -->
   <!-- Record session replays for 100% of errors and 10% of sessions -->
   <meta-data android:name="io.sentry.session-replay.on-error-sample-rate" android:value="1.0" />
   <meta-data android:name="io.sentry.session-replay.session-sample-rate" android:value="0.1" />
+  <!-- ___PRODUCT_OPTION_END___ session-replay -->
 </application>
 ```
 

docs/platforms/android/logs/index.mdx

@@ -0,0 +1,30 @@
+---
+title: Set Up Logs
+sidebar_title: Logs
+description: "Structured logs allow you to send, view and query logs sent from your applications within Sentry."
+sidebar_order: 5755
+---
+
+<Include name="feature-stage-beta-logs.mdx" />
+
+With Sentry Structured Logs, you can send text based log information from your applications to Sentry. Once in Sentry, these logs can be viewed alongside relevant errors, searched by text-string, or searched using their individual attributes.
+
+## Requirements
+
+<PlatformContent includePath="logs/requirements" />
+
+## Setup
+
+<PlatformContent includePath="logs/setup" />
+
+## Usage
+
+<PlatformContent includePath="logs/usage" />
+
+## Integrations
+
+<PlatformContent includePath="logs/integrations" />
+
+## Options
+
+<PlatformContent includePath="logs/options" />

docs/platforms/android/manual-setup/index.mdx

@@ -49,10 +49,12 @@ Configuration is done via the application `AndroidManifest.xml`. Here's an examp
   <!-- enable the performance API by setting a sample-rate, adjust in production env -->
   <meta-data android:name="io.sentry.traces.sample-rate" android:value="1.0" />
 
-  <!-- enable profiling when starting transactions, adjust in production env -->
-  <meta-data android:name="io.sentry.traces.profiling.sample-rate" android:value="1.0" />
-  <!-- enable app start profiling -->
-  <meta-data android:name="io.sentry.traces.profiling.enable-app-start" android:value="true" />
+  <!-- Enable UI profiling, adjust in production env. This is evaluated only once per session -->
+  <meta-data android:name="io.sentry.traces.profiling.session-sample-rate" android:value="1.0" />
+  <!-- Set profiling mode. For more info see https://docs.sentry.io/platforms/android/profiling/#enabling-ui-profiling -->
+  <meta-data android:name="io.sentry.traces.profiling.lifecycle" android:value="trace" />
+  <!-- Enable profiling on app start. The app start profile will be stopped automatically when the app start root span finishes -->
+  <meta-data android:name="io.sentry.traces.profiling.start-on-app-start" android:value="true" />
 
   <!-- record session replays for 100% of errors and 10% of sessions -->
   <meta-data android:name="io.sentry.session-replay.on-error-sample-rate" android:value="1.0" />

docs/platforms/android/metrics/index.mdx

@@ -1,5 +1,6 @@
 ---
 title: Set Up Metrics
+sidebar_title: Metrics
 description: "Learn how to measure the data points you care about by configuring Metrics in your Android app."
 sidebar_order: 5500
 sidebar_hidden: true

docs/platforms/android/migration/index.mdx

@@ -442,7 +442,7 @@ SentryOptions#addEventProcessor(object : EventProcessor {
 })
 ```
 
-A random generated `installationId` replaces `Settings.Secure.ANDROID_ID`, which has been removed. This may affect the number of unique users displayed on the the Issues page and Alerts.
+A random generated `installationId` replaces `Settings.Secure.ANDROID_ID`, which has been removed. This may affect the number of unique users displayed on the Issues page and Alerts.
 If you always set a custom user using `Sentry.setUser(customUser)`, the behavior has not changed. While you don't have to make any update, if you want to maintain the old behavior, use the following code snippet:
 
 ```java

docs/platforms/android/profiling/index.mdx

@@ -1,5 +1,6 @@
 ---
-title: Set Up Profiling
+title: Set Up Android Profiling
+sidebar_title: Profiling
 description: "Learn how to enable profiling in your app if it is not already set up."
 sidebar_order: 5000
 ---

docs/platforms/android/sentry-prevent/index.mdx

@@ -0,0 +1,10 @@
+---
+title: Sentry Prevent
+sidebar_order: 2000
+caseStyle: camelCase
+description: "Sentry Prevent documentation for android"
+---
+
+# Sentry Prevent for android
+
+Documentation for Sentry Prevent features in android.

docs/platforms/android/sentry/configuration/app-not-respond.mdx

@@ -0,0 +1,127 @@
+---
+title: Application Not Responding (ANR)
+sidebar_order: 4
+description: "Learn how to turn off or specify ANR."
+---
+
+Application Not Responding (ANR) errors are triggered when the main UI thread of an application is blocked for more than five seconds. The Android SDK reports ANR errors as Sentry events. In addition, Sentry calculates [ANR rate](/platforms/android/tracing/instrumentation/performance-metrics/#application-not-responding-anr-rate) based on these events and user sessions.
+
+## ANR implementation details
+
+The Android SDK uses different implementations to detect ANRs, depending on what version of Android the device is running:
+
+- Below Android 11: Running a Watchdog thread (v1)
+- Android 11 and above: Reading [ApplicationExitInfo](https://developer.android.com/reference/android/app/ApplicationExitInfo) (v2)
+
+The new implementation (v2) uses the same data source as Google Play Console. This means the reported ANR events and [ANR rate](/platforms/android/tracing/instrumentation/performance-metrics/#application-not-responding-anr-rate) should match with what you see on Sentry. The new implementation also captures a thread dump with additional information, like held locks, to help you resolve ANRs more efficiently.
+
+While the original Watchdog approach (v1) reports many false positives and is based on heuristics, it still has some advantages over v2, like capturing screenshots and transactions with profiles at the time of ANR.
+
+<Alert>
+
+We're considering SDK support for both approaches working alongside each other on Android 11 and up. Please upvote [this GitHub discussion](https://github.com/getsentry/sentry-java/discussions/2716) and share your feedback if you have a case for v1 and v2 working together.
+
+</Alert>
+
+Both ANR detection implementations are controlled by the same flag:
+
+```xml {filename:AndroidManifest.xml}
+<application>
+    <meta-data android:name="io.sentry.anr.enable" android:value="false" />
+</application>
+```
+
+### Watchdog (v1)
+
+Whenever the main UI thread of the application is blocked for more than five seconds, the SDK will report the problem to the server.
+
+The integration reports ANR events with `mechanism:ANR`.
+
+<Alert>
+
+Sentry does not report the ANR if the application is in debug mode.
+
+</Alert>
+
+You can also specify how long the thread should be blocked before the ANR is reported. Provide the duration in the attribute `io.sentry.anr.timeout-interval-millis` in your `AndroidManifest.xml`:
+
+```xml {filename:AndroidManifest.xml}
+<application>
+    <meta-data android:name="io.sentry.anr.timeout-interval-millis" android:value="2000" />
+</application>
+```
+
+### ApplicationExitInfo (v2)
+
+This approach reads the [ApplicationExitInfo](https://developer.android.com/reference/android/app/ApplicationExitInfo) API on the next app launch
+and asynchronously sends ANR events to Sentry for each ANR in the history, enriching only the latest one with breadcrumbs, contexts, tags, etc.
+
+The integration reports ANR events with `mechanism:AppExitInfo`.
+
+<Alert>
+
+If [ApplicationExitInfo#getTraceInputStream](<https://developer.android.com/reference/android/app/ApplicationExitInfo#getTraceInputStream()>) returns `null`, the SDK will no longer report an ANR event, since these events won't be actionable without it.
+
+</Alert>
+
+![ANR](./img/app-not-respond.png)
+
+#### Historical ANRs
+
+By default, the SDK only reports and enriches the latest ANR and it's the only one counted towards the ANR rate. However, there's also a `setReportHistoricalAnrs` option available in `SentryOptions`, which enables the SDK to report all ANRs from the [getHistoricalExitReasons](<https://developer.android.com/reference/android/app/ActivityManager?hl=en#getHistoricalProcessExitReasons(java.lang.String,%20int,%20int)>) list:
+
+```kotlin
+SentryAndroid.init(context) { options ->
+  options.isReportHistoricalAnrs = true
+}
+```
+
+```java
+SentryAndroid.init(context) { options ->
+  options.setReportHistoricalAnrs(true)
+}
+```
+
+This option is useful after updating the SDK to the version where the new ANR implementation was introduced, in order to report all ANRs that took place prior to the SDK update. Other than that, the SDK will always pick up the latest ANR from the historical exit reasons list on next app restart, and there won't be any historical ANRs to report.
+
+The integration reports ANR events with `mechanism:HistoricalAppExitInfo`.
+
+#### Attaching Thread Dump
+
+The SDK makes it possible to send the ANR thread dump from [ApplicationExitInfo#getTraceInputStream](<https://developer.android.com/reference/android/app/ApplicationExitInfo#getTraceInputStream()>) as an attachment. This is useful for performing deeper investigations using all available information from the OS (in addition to the SDK parsing the thread dump into threads with stack traces):
+
+```kotlin
+SentryAndroid.init(context) { options ->
+  options.isAttachAnrThreadDump = true
+}
+```
+
+```java
+SentryAndroid.init(context) { options ->
+  options.setAttachAnrThreadDump(true)
+}
+```
+
+![ANR Thread Dump](./img/app-not-respond-thread-dump.png)
+
+## ANR Root Cause Analysis
+
+Sentry performs various root cause analyses to give you insights about why certain ANRs might appear. If a potential root cause is detected, it'll be displayed in a new section below the ANR stack trace. Sentry can detect the following root causes:
+
+### Performance Issues
+
+If an ANR is connected to one of the Performance Issues detected by Sentry (for example, [File I/O on Main Thread](/product/issues/issue-details/performance-issues/file-main-thread-io/) or [DB on Main Thread](/product/issues/issue-details/performance-issues/db-main-thread-io/)), the offending span will be linked to the ANR event, showing you exactly which slow operation is to blame.
+
+![ANR Root Cause File I/O](./img/anr-rootcause-fileio.png)
+
+### Common Patterns
+
+This detector looks at the stack trace of an ANR and tries to identify common pitfalls, such as accessing files, assets, or heavy resources on the main thread. If an offending stack frame is found, it'll be highlighted in the stack trace with some information about how to prevent this type of ANR:
+
+![ANR Root Cause Suspect Frame](./img/anr-rootcause-frame.png)
+
+### Deadlock Detection
+
+Sentry will try to detect deadlocks and point out potential causes. If, for example, the main thread is blocked by waiting on a lock object that's held by another thread, the suspect frame that's waiting on the lock will be highlighted. The stack trace of the offending thread that's holding the lock, as well as the offending frame of that thread will also be shown:
+
+![ANR Root Cause Deadlock](./img/anr-rootcause-deadlock.png)

docs/platforms/android/sentry/configuration/bill-of-materials.mdx

@@ -0,0 +1,15 @@
+---
+title: Using a BOM
+description: "Learn more about using a bill of materials with multiple Sentry dependencies."
+sidebar_order: 1000
+---
+
+When you are using multiple Sentry dependencies, you can avoid specifying the version of each dependency with a _BOM_ or _Bill Of Materials_.
+
+Using Gradle 5.0 or higher, you can add the following to the `dependencies` section in your `build.gradle`:
+
+```groovy {filename:build.gradle}
+implementation platform('io.sentry:sentry-bom:{{@inject packages.version('sentry.java.bom', '5.1.0') }}') //import bom
+implementation('io.sentry:sentry-android') //no version specified
+implementation('io.sentry:sentry-android-fragment') //no version specified
+```

docs/platforms/android/sentry/configuration/draining.mdx

@@ -0,0 +1,10 @@
+---
+title: Shutdown and Draining
+sidebar_order: 70
+description: "Learn more about the default behavior of our SDK if the application shuts down unexpectedly."
+---
+
+The default behavior of most SDKs is to send out events over the network
+asynchronously in the background. This means that some events might be lost if the application shuts down unexpectedly. The SDKs provide mechanisms to cope with this.
+
+<PlatformContent includePath="configuration/drain-example" />

docs/platforms/android/sentry/configuration/environments.mdx

@@ -0,0 +1,15 @@
+---
+title: Environments
+sidebar_order: 30
+description: "Learn how to configure your SDK to tell Sentry about your environments."
+---
+
+Environments tell you where an error occurred, whether that's in your production system, your staging server, or elsewhere.
+
+Sentry automatically creates an environment when it receives an event with the `environment` parameter set.
+
+Environments are case-sensitive. The environment name can't contain newlines, spaces or forward slashes, can't be the string "None", or exceed 64 characters. You can't delete environments, but you can [hide](/product/sentry-basics/environments/#hidden-environments) them.
+
+<PlatformContent includePath="set-environment" />
+
+Environments help you better filter issues, releases, and user feedback in the Issue Details page of sentry.io, which you learn more about in our [documentation that covers using environments](/product/sentry-basics/environments/).