You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 8d299fc
Browse filesBrowse the repository at this point in the historyBrowse files
perf(android): Init shake detector off the main thread (#5784)
* perf(android): Init shake detector off the main thread (JAVA-618)
FeedbackShakeIntegration.register() resolved the accelerometer via
SensorManager synchronously on the calling thread, which under auto-init
is the main thread. On a Pixel 10 this first SensorManager access
measured ~1.75ms, making it the single most expensive integration in the
Sentry.init register loop.
Submit the pre-warm init() to the executor service instead. start()
already re-runs the idempotent init() on demand, so shake detection still
works if an activity resumes before the warm-up completes. SentryShakeDetector's
lifecycle methods are now synchronized so the executor warm-up and a
main-thread start() cannot race on the sensor fields.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
* docs: Add changelog for shake-detector init off main thread (JAVA-618)
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
* fix(android): Guard shake detector against warm-up after close (JAVA-618)
A warm-up init submitted to the executor could be drained after the
integration's close() ran, since integrations shut down before the
executor. That re-resolved the sensor and leaked a HandlerThread. Guard
init()/start() with a closed latch so a late warm-up is a no-op.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
* fix(android): Re-arm shake detector on re-register (JAVA-618)
The closed latch added to neutralize a warm-up drained after close()
was permanent, so re-registering the same integration (e.g. a second
Sentry.init reusing the same options) left shake detection off with no
recovery. register() now re-arms the detector via reopen(), which the
stale-warm-up path (init()) deliberately does not, preserving the
drain-after-close guard.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
Copy file name to clipboardExpand all lines: CHANGELOG.md
+1Lines changed: 1 addition & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -4,6 +4,7 @@
4
4
5
5
### Fixes
6
6
7
+
- Reduce main-thread work during `Sentry.init` by resolving the shake-detector accelerometer off the main thread (~1.75ms on a Pixel 10) ([#5784](https://github.com/getsentry/sentry-java/pull/5784))
7
8
- Backfill release, environment, distribution, tags, and app version/build—and use the matching replay-on-error sample rate—for `ApplicationExitInfo` ANR and native crash events captured before SDK initialization, without reusing options cached by a later app update ([#5762](https://github.com/getsentry/sentry-java/pull/5762))
8
9
- `SentryTagModifierNode.isImportantForBounds` now matches the default behavior and returns `true` ([#5789](https://github.com/getsentry/sentry-java/pull/5789))
9
10
- Prevent a `StackOverflowError` when a `beforeSend`, `beforeBreadcrumb`, `beforeSendLog`, or `beforeEnvelope` callback triggers another capture (directly or through a logging integration such as Timber) ([#5737](https://github.com/getsentry/sentry-java/pull/5737))
0 commit comments