Bump io.sentry:sentry-bom from 7.17.0 to 8.17.0

[dependabot]

Related: AINFRA-499

Bumps io.sentry:sentry-bom from 7.17.0 to 8.17.0.

Release notes

Sourced from io.sentry:sentry-bom's releases.

8.16.1-alpha.2

Fixes

• Optimize scope when maxBreadcrumb is 0 (#4504)
• Fix javadoc on TransportResult (#4528)
• Session Replay: Fix IllegalArgumentException when Bitmap is initialized with non-positive values (#4536)
• Set thread information on transaction from OpenTelemetry attributes (#4478)

Internal

• Flattened PerformanceCollectionData (#4505)

8.16.0

Features

• Send JUL logs to Sentry as logs (#4518)
  • You need to enable the logs feature, either in sentry.properties:

    logs.enabled=true

  • Or, if you manually initialize Sentry, you may also enable logs on Sentry.init:

    Sentry.init(options -> {
      ...
      options.getLogs().setEnabled(true);
    });

  • It is also possible to set the minimumLevel in logging.properties, meaning any log message >= the configured level will be sent to Sentry and show up under Logs:

    io.sentry.jul.SentryHandler.minimumLevel=CONFIG

• Send Log4j2 logs to Sentry as logs (#4517)
  • You need to enable the logs feature either in sentry.properties:

    logs.enabled=true

  • If you manually initialize Sentry, you may also enable logs on Sentry.init:

    Sentry.init(options -> {
      ...
      options.getLogs().setEnabled(true);
    });

  • It is also possible to set the minimumLevel in log4j2.xml, meaning any log message >= the configured level will be sent to Sentry and show up under Logs:

    <Sentry name="Sentry"
        dsn="your DSN"
        minimumBreadcrumbLevel="DEBUG"
        minimumEventLevel="WARN"
        minimumLevel="DEBUG"

... (truncated)

Changelog

Sourced from io.sentry:sentry-bom's changelog.

Changelog

Unreleased

Features

• Send Timber logs through Sentry Logs (#4490)
  • Enable the Logs feature in your SentryOptions or with the io.sentry.logs.enabled manifest option and the SDK will automatically send Timber logs to Sentry, if the TimberIntegration is enabled.
  • The SDK will automatically detect Timber and use it to send logs to Sentry.
• Send logcat through Sentry Logs (#4487)
  • Enable the Logs feature in your SentryOptions or with the io.sentry.logs.enabled manifest option and the SDK will automatically send logcat logs to Sentry, if the Sentry Android Gradle plugin is applied.
  • To set the logcat level check the Logcat integration documentation.
• Read build tool info from sentry-debug-meta.properties and attach it to events (#4314)

Dependencies

• Bump OpenTelemetry (#4532)
  • opentelemetry-sdk to 1.51.0
  • opentelemetry-instrumentation to 2.17.0
  • opentelemetry-javaagent to 2.17.0
  • opentelemetry-semconv to 1.34.0
  • We are now configuring OpenTelemetry to still behave the same way it did before for span names it generates in GraphQL auto instrumentation (#4537)

Fixes

• Use Spring Boot Starter 3 in sentry-spring-boot-starter-jakarta (#4545)
  • While refactoring our dependency management, we accidentally added Spring Boot 2 and Spring Boot Starter 2 as dependencies of sentry-spring-boot-starter-jakarta, which is intended for Spring Boot 3.
  • Now, the correct dependencies (Spring Boot 3 and Spring Boot Starter 3) are being added.

8.16.1-alpha.2

Fixes

• Optimize scope when maxBreadcrumb is 0 (#4504)
• Fix javadoc on TransportResult (#4528)
• Session Replay: Fix IllegalArgumentException when Bitmap is initialized with non-positive values (#4536)
• Set thread information on transaction from OpenTelemetry attributes (#4478)

Internal

• Flattened PerformanceCollectionData (#4505)

8.16.0

Features

• Send JUL logs to Sentry as logs (#4518)
  • You need to enable the logs feature, either in sentry.properties:

    logs.enabled=true

... (truncated)

Commits

• See full diff in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[wzieba]

Looks good

The list of breaking and behavioral changes introduced with the major release is quite long (link) but it seems it doesn't affect us.

[wzieba]

I've also sent the release notes of 8.0 release to Junie and asked if the project is compatible, which confirms things look good

Impact of Sentry 8.17.0 Update on Automattic-Tracks-Android Project

Based on my analysis of the Sentry 8.17.0 release notes and the project's codebase, the update should have minimal impact on this project. Here's a detailed assessment:

✅ No Breaking Changes Detected

The project appears to be well-positioned for the Sentry 8.x upgrade:

1. Minimum SDK Compatibility: The project already uses minSdkVersion = 21, which meets Sentry 8.x's new requirement (bumped from 19 to 21).

2. Dependencies: The project uses:

   • sentry-android-core ✅
   • sentry-okhttp ✅ (not the deprecated sentry-android-okhttp)
   • sentry-android-fragment ✅
   • sentry-compose-android ✅

3. No Deprecated API Usage: The codebase doesn't use any of the deprecated/removed APIs mentioned in the breaking changes:

   • No Hub usage (replaced by Scopes)
   • No deprecated methods like Sentry.traceHeaders() or Sentry.reportFullDisplayed()
   • No deprecated configuration options like enableTracing, traceOrigins, profilingEnabled
   • No deprecated manifest options

🔄 Behavioral Changes That May Affect the Project

1. Scope Management:

   • The project uses standard Sentry APIs (Sentry.setUser(), Sentry.setTag(), Sentry.addBreadcrumb())
   • These will now work with the new Scopes system instead of Hub, but the API remains the same
   • For Android, the default scope type is CURRENT, which should maintain existing behavior

2. Performance Monitoring:

   • The project uses tracesSampleRate and profilesSampleRate correctly
   • Performance V2 is now enabled by default, which may provide more detailed spans for app startup

3. IP Address Collection:

   • User IP addresses are now only set to "{{auto}}" if sendDefaultPii is enabled
   • This gives more control over IP collection on the client side

4. Session Tracking:

   • isEnableAutoSessionTracking = true is already used correctly
   • No changes needed for session tracking configuration

📋 Configuration Analysis

The project's Sentry configuration in SentryCrashLogging.kt is compatible:

options.apply {
    dsn = dataProvider.sentryDSN
    environment = dataProvider.buildType
    tracesSampleRate = tracesSampleRate  // ✅ Correct way to enable performance
    profilesSampleRate = profilesSampleRate  // ✅ Correct configuration
    isEnableAutoSessionTracking = true  // ✅ Compatible
    // ... other configurations are also compatible
}

🎯 Conclusion

The Sentry 8.17.0 update should NOT significantly affect this project's behavior. The project:

• Uses compatible dependencies
• Follows current best practices
• Doesn't rely on deprecated APIs
• Has proper minimum SDK version

The main benefits will be:

• Better performance monitoring with Performance V2
• Improved scope management under the hood
• Enhanced OpenTelemetry integration capabilities (if needed in the future)
• Better trace propagation and context management

Recommendation: The update can be applied safely with minimal risk of breaking changes.

[wzieba]

cc: @ParaskP7 as this also makes Tracks 16kb-compatible

[ParaskP7]

Oh cool, yes, I've been following this update for a while, thanks for reviewing/testing/merging this @wzieba ! 💯 🙇 🚀