# Releases & Health | Sentry for Android

A release is a version of your code that is deployed to an [environment](https://docs.sentry.io/platforms/android/configuration/environments.md). When you give Sentry information about your releases, you can:

* Determine issues and regressions introduced in a new release
* Predict which commit caused an issue and who is likely responsible
* Resolve issues by including the issue number in your commit message
* Receive email notifications when your code gets deployed

Additionally, releases are used for applying [source maps](https://docs.sentry.io/platforms/javascript/sourcemaps.md) to minified JavaScript to view original, untransformed source code.

## [Bind the Version](https://docs.sentry.io/.md#bind-the-version)

Include a release ID (often called a "version") when you initialize the SDK.

The release name cannot:

* contain newlines, tabulator characters, forward slashes(`/`) or back slashes(`\`)
* be (in their entirety) period (`.`), double period (`..`), or space ( )
* exceed 200 characters

The value can be arbitrary, but we recommend either of these naming strategies:

* **Semantic Versioning**: `package@version` or `package@version+build` (for example, `my.project.name@2.3.12+1234`)

  * `package` is the unique identifier of the project/app (`CFBundleIdentifier` on iOS, `packageName` on Android)
  * `version` is the semver-like structure `<major>.<minor?>.<patch?>.<revision?>-<prerelease?>` (`CFBundleShortVersionString` on iOS, `versionName` on Android)
  * `build` is the number that identifies an iteration of your app (`CFBundleVersion` on iOS, `versionCode` on Android)

* **Commit SHA**: If you use a version control system like Git, we recommend using the identifying hash (for example, the commit SHA, `da39a3ee5e6b4b0d3255bfef95601890afd80709`). You can let Sentry CLI automatically determine this hash for supported version control systems. Learn more in our [Sentry CLI](https://docs.sentry.io/cli/releases.md#creating-releases) documentation.

Releases are global per organization; prefix them with something project-specific for easy differentiation.

The behavior of a few features depends on whether a project is using semantic or time-based versioning.

* Regression detection
* `release:latest`

We automatically detect whether a project is using semantic or time-based versioning based on:

* If ≤ 2 releases total: we look at most recent release.
* If 3-9 releases (inclusive): if any of the most recent 3 releases is semver, project is semver.
* If 10 or more releases: if any of the most recent 3 releases is semver, and 3 out of the most recent 10 releases is semver, then the project is semver.

## [Setting a Release](https://docs.sentry.io/.md#setting-a-release)

`AndroidManifest.xml`

```xml
<application>
  <meta-data
    android:name="io.sentry.release"
    android:value="io.example@1.1.0"
  />
</application>
```

Or, if you are manually instrumenting Sentry:

```java
SentryAndroid.init(this, options -> {
  options.setRelease("io.example@1.1.0");
});
```

If no release name is set the SDK creates a default combined of `packageName, versionName and versionCode`, for example `my.project.name@2.3.12+1234`.

How you make the release name (or version) available to your code is up to you. For example, you could use an environment variable that is set during the build process or during initial start-up.

Setting the release name tags each event with that release name. We recommend that you tell Sentry about a new release before sending events with that release name, as this will unlock a few more features. Learn more in our [Releases](https://docs.sentry.io/product/releases.md) documentation.

If you don't tell Sentry about a new release, Sentry will automatically create a release entity in the system the first time it sees an event with that release ID.

After configuring your SDK, you can install a repository integration or manually supply Sentry with your own commit metadata. Read our documentation about [setting up releases](https://docs.sentry.io/product/releases/setup.md) for further information about integrations, associating commits, and telling Sentry when deploying releases.

## [Release Health](https://docs.sentry.io/.md#release-health)

Monitor the [health of releases](https://docs.sentry.io/product/releases/health.md) by observing user adoption, usage of the application, percentage of [crashes](https://docs.sentry.io/product/releases/health.md#crash), and [session data](https://docs.sentry.io/product/releases/health.md#session). Release health will provide insight into the impact of crashes and bugs as it relates to user experience, and reveal trends with each new issue through the [Release Details](https://docs.sentry.io/product/releases/release-details.md) graphs and filters.

Crash reporting and app hang detection are not available for watchOS.

In order to monitor release health, the SDK sends session data.

### [Sessions](https://docs.sentry.io/.md#sessions)

A session represents the interaction between the user and the application. Sessions contain a timestamp, a status (if the session was OK or if it crashed), and are always linked to a release. Most Sentry SDKs can manage sessions automatically.

To benefit from the health data, you must use at least version 2.1.0 of the Android SDK, and enable the collection of release health metrics in the initialization options for the SDK. Release health is captured, by default, in our Android version 3.0 and higher, unless you specifically disabled collecting it in the initialization options for the SDK.

By default, the session is terminated once the application is in the background for more than 30 seconds. You can change the time out with the option named `sessionTrackingIntervalMillis`. It takes the amount in milliseconds. For example, to configure it to be 60 seconds:

`AndroidManifest.xml`

```xml
<application>
  <meta-data
    android:name="io.sentry.session-tracking.timeout-interval-millis"
    android:value="60000"
  />
</application>
```

Or, if you are manually instrumenting Sentry:

```java
import io.sentry.android.core.SentryAndroid;

SentryAndroid.init(this, options -> {
  options.setSessionTrackingIntervalMillis(60000);
});
```

If you'd like to opt-out of this feature, you can do it via options.

`AndroidManifest.xml`

```xml
<application>
  <meta-data
    android:name="io.sentry.auto-session-tracking.enable"
    android:value="true"
  />
</application>
```

Or, if you are manually instrumenting Sentry:

```java
import io.sentry.android.core.SentryAndroid;

SentryAndroid.init(this, options -> {
  options.setEnableAutoSessionTracking(true);
});
```

### [AndroidX Support](https://docs.sentry.io/.md#androidx-support)

Sentry uses the `androidx.lifecycle` libraries for detecting when the application is either in the background or in the foreground. This is necessary for producing accurate results across all the Android OS versions.

We check at runtime for availability, so if you're not using `androidx.lifecycle` libraries, you can remove them from Sentry's transitive dependencies.

```Groovy
implementation ('io.sentry:sentry-android:8.17.0') {
    exclude group: 'androidx.lifecycle', module: 'lifecycle-process'
    exclude group: 'androidx.lifecycle', module: 'lifecycle-common-java8'
}
```

Be aware that by removing those transitive dependencies, the automatic session tracking won't work, but you can still do it manually by calling the public APIs `Sentry.startSession()` and `Sentry.endSession()`.
