[8.x] Backport manual Logs and Metrics API ungating without changing automatic collection

[sentry-junior]

Goal

Ship the manual-API portion of the Logs/Metrics enable-flag work in an 8.x minor release, without waiting for v9 or backporting its public API removal / integration-default changes.

Explicit calls to Sentry.logger() and Sentry.metrics() must be captured even when options.getLogs().setEnabled(false) or options.getMetrics().setEnabled(false) is configured, subject to normal SDK enablement, filtering and transport behavior.

Keep the existing public options and their defaults in 8.x. Preserve existing automatic-collection behavior; in particular, removing a manual-API gate must not turn on framework/library log forwarding for users who disabled it.

Code inspected

Static inspection of tag 8.58.0, current main b59e639, and open stack tip #5970 at 8eeaffb. No implementation or runtime tests performed for this issue.

At inspection time, main reports versionName=8.58.0; no literal 8.x branch was found. Target the maintained 8.x release line / branch selected by maintainers.

1. There are two gates, not just the public API checks

• LoggerApi checks options.getLogs().isEnabled().
• MetricsApi checks options.getMetrics().isEnabled().
• SentryClient constructor installs NoOpLoggerBatchProcessor / NoOpMetricsBatchProcessor when the flags are false.

Deleting only the API checks would still silently discard the items. Real batch processors must be available independently of these flags, while preserving custom factory behavior.

2. Android Timber needs a compatibility guard

8.58.0 SentryTimberTree.addLog checks the log level but then calls scopes.logger().log(...) without its own enable-flag check. It currently relies on the core gate.

Ungating the core alone would allow Timber to start sending Logs even with the legacy logs flag false. Preserve 8.x behavior by guarding automatic Timber forwarding at the integration boundary (reading the current option, rather than freezing a potentially premature value). Do not gate direct user calls again.

Logback, Log4j2, JUL and SentryLogcatAdapter already contain local Logs enable checks in the inspected code; retain and test them. Include Spring Boot auto-wiring. Check mixed-artifact compatibility: upgrading core while leaving an older Timber integration installed can bypass a fix that lives only in the new Timber artifact; document/enforce aligned versions or explicitly address this case.

3. Avoid unnecessary worker activity

The existing batch processors schedule work from flush() and restarting close() even if no items were accepted. Once processors are created unconditionally, this can start previously absent worker threads for SDK users who never call these APIs. Evaluate the narrowly scoped protections from #5952 and #5957 and test empty flush/restart/close as well as normal batching/concurrency.

Implementation approach

Adapt the relevant behavior from #5947 (Logs) and #5953 (Metrics), rather than wholesale cherry-picking the v9 stack. Preserve the 8.x Logs / Metrics enable accessors, defaults, external configuration, Android manifest and Spring property binding. Keep automatic log gating at integration boundaries. Leave public option removal, new required integration opt-ins, and warnings saying the legacy log setting is entirely ignored to the major release.

Related Timber work: #5943 and #5964. Full stack reference: #5970.

Acceptance criteria

• Direct Logs calls work with the Logs flag omitted, true and false; direct Metrics calls work with the Metrics flag true and false.
• Tests cover the real SentryClient / batch-processor / transport path, not only mocked ISentryClient API calls.
• Entire SDK disabled / uninitialized / closed behavior remains unchanged; before-send callbacks and other normal delivery controls still apply.
• No automatic Logs from Timber, Logcat, Logback, Log4j2, JUL or Spring Boot when the legacy Logs flag is false; existing true behavior, breadcrumbs and error capture are preserved.
• Any automatic metric producers on the target line are audited so manual ungating does not opt them in implicitly.
• No unused-worker regression on empty flush, close or SDK reinitialization; normal flush/shutdown, queue limits and custom batch-processor factories continue working.
• Public API/binary compatibility and existing config binding remain intact in 8.x; mixed-version Timber/core behavior is explicitly addressed.
• Changelog and docs explain the intentional minor-release behavior change: manual API calls no longer honor the telemetry kill switches, but automatic logging still honors the legacy setting in 8.x. Explain before-send filtering for users who need to drop manually emitted telemetry.

Tracking

Related umbrella issues: #5364 (Java), #5363 (Android). This issue is specifically the 8.x minor-compatible manual-API backport, not a replacement for the major-transition work. Focused GitHub and Linear searches did not find a dedicated backport ticket.

[linear-code]

JAVA-747