ADFA-4397: Migrate crash and log reporting from Sentry to GlitchTip - #1490
Conversation
Point the Sentry Android SDK at GlitchTip instead of Sentry. The SDK, DSN format, and tooling stay the same; only the endpoint moves. The DSN comes from local.properties for local builds and from CI secrets for release builds, so nothing is hardcoded. - Forward the app's logback output to GlitchTip. WARN and above go to the Logs view; INFO and above ride along as breadcrumbs (breadcrumbs are free). - Tag each event with the device as the user so crashes can be filtered per user. - Drop Sentry features GlitchTip does not support: session replay and profiling (dependency plus manifest flags removed). - Keep event volume inside the 100k plan: error logs no longer become issues (real crashes are still captured), and performance transactions are disabled. Logs bill at 0.1 and share the same event pool.
![claude[bot]](https://cdn.github.com/in/1236702?s=60&v=4){kind=small}
There was a problem hiding this comment.
Claude Code Review
This repository is configured for manual code reviews. Comment @claude review for a one-time review, or @claude review always to subscribe this PR to a review on every future push.
Tip: disable this comment in your organization's Code Review settings.
📝 Walkthrough
WalkthroughThis PR replaces Sentry session replay with Logback-based logging, routes a shared GlitchTip DSN through build and workflow configuration, updates Sentry initialization with a Logback appender and device user data, and reduces Sentry manifest metadata. ChangesSentry Logback Migration
Estimated code review effort: 4 (Complex) | ~40 minutes Sequence Diagram(s)sequenceDiagram
participant ApplicationLoader
participant SentryAndroid
participant Logback
participant SentryAppender
participant Sentry
ApplicationLoader->>SentryAndroid: initialize Sentry options
ApplicationLoader->>Logback: obtain root logger
ApplicationLoader->>SentryAppender: configure logging thresholds
ApplicationLoader->>Logback: attach SentryAppender
ApplicationLoader->>Sentry: set device user data
Suggested reviewers: Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://cdn.github.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
app/build.gradle.kts (1)
357-360: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winStale comment references removed replay dependency.
The comment above still says "core + replay for quality configuration" but
sentry.android.replaywas removed andsentry.logbackwas added.📝 Proposed fix
- // Sentry Android SDK (core + replay for quality configuration) + // Sentry Android SDK (core + Logback appender for GlitchTip log/breadcrumb forwarding) implementation(libs.sentry.core) implementation(libs.sentry.android.core) implementation(libs.sentry.logback)🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@app/build.gradle.kts` around lines 357 - 360, The dependency block for the Sentry Android SDK has a stale comment that still references replay even though only core, android core, and logback are included now. Update the comment near the Sentry dependency declarations to match the actual set of dependencies in the build script, using the existing Sentry dependency entries as the reference point.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In
`@app/src/main/java/com/itsaky/androidide/app/DeviceProtectedApplicationLoader.kt`:
- Around line 75-97: Wrap the Sentry and Logback initialization in
DeviceProtectedApplicationLoader.load() in a runCatching block so
startup-critical failures do not abort direct-boot setup. Keep the existing
SentryAndroid.init, LoggerContext/SentryAppender configuration, and
Sentry.setUser logic inside the guarded block, and make sure any exception is
swallowed or logged without preventing the later ShizukuSettings.initialize()
and EventBus setup from running.
---
Nitpick comments:
In `@app/build.gradle.kts`:
- Around line 357-360: The dependency block for the Sentry Android SDK has a
stale comment that still references replay even though only core, android core,
and logback are included now. Update the comment near the Sentry dependency
declarations to match the actual set of dependencies in the build script, using
the existing Sentry dependency entries as the reference point.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 79fe817f-c893-4847-8028-6adf51828d4e
📒 Files selected for processing (4)
app/build.gradle.ktsapp/src/main/AndroidManifest.xmlapp/src/main/java/com/itsaky/androidide/app/DeviceProtectedApplicationLoader.ktgradle/libs.versions.toml
…init - Read one glitchtipDsn / GLITCHTIP_DSN for both debug and release builds and drop the unused SENTRY_ORG, SENTRY_PROJECT, and SENTRY_AUTH_TOKEN. - Wrap SentryAndroid.init, the logback appender setup, and Sentry.setUser in runCatching so a failure is logged and direct-boot startup still runs ShizukuSettings and the EventBus.
# Conflicts: # app/src/main/java/com/itsaky/androidide/app/DeviceProtectedApplicationLoader.kt
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
.github/workflows/release.yml (1)
28-28: 🎯 Functional Correctness | 🟠 Major | ⚡ Quick winFail the release build when
GLITCHTIP_DSNis missing.
app/build.gradle.ktsconverts a missing DSN into"", so this workflow can publish a release APK with crash/log reporting silently disabled. Add a non-empty check before assembling the APK.Proposed validation
+ - name: Validate GlitchTip DSN + run: | + if [ -z "$GLITCHTIP_DSN" ]; then + echo "ERROR: GLITCHTIP_DSN secret is not set" + exit 1 + fi🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/release.yml at line 28, Update the release workflow to validate that GLITCHTIP_DSN is present and non-empty before the APK assembly step. Make the validation fail the job with a clear error when the secret is missing, while preserving the existing GLITCHTIP_DSN environment wiring for the build.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Outside diff comments:
In @.github/workflows/release.yml:
- Line 28: Update the release workflow to validate that GLITCHTIP_DSN is present
and non-empty before the APK assembly step. Make the validation fail the job
with a clear error when the secret is missing, while preserving the existing
GLITCHTIP_DSN environment wiring for the build.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: e9e667ed-63ae-4282-a8b7-a69272ac5aaf
📒 Files selected for processing (6)
.github/workflows/debug.yml.github/workflows/release.ymlapp/build.gradle.ktsapp/src/main/AndroidManifest.xmlapp/src/main/java/com/itsaky/androidide/app/DeviceProtectedApplicationLoader.ktgradle/libs.versions.toml
🚧 Files skipped from review as they are similar to previous changes (4)
- app/src/main/AndroidManifest.xml
- gradle/libs.versions.toml
- .github/workflows/debug.yml
- app/build.gradle.kts
5 participants
Point the Sentry Android SDK at GlitchTip instead of Sentry. The SDK, DSN format, and tooling stay the same; only the endpoint moves. The DSN comes from local.properties for local builds and from CI secrets for release builds, so nothing is hardcoded.