feat(sentry): land Phases 6 + 7a — Android exit reasons & iOS MetricKit app-exit telemetry

[gmaclennan]

Post-mortem visibility on OS-driven kills, answering "does our backend stay alive long enough on this user's device?" per platform.

Android (Phase 6)

ExitReasonsCollector surfaces ActivityManager.getHistoricalProcessExitReasons() records (API 30+) as "android exit: REASON_*" events on the next process start:

• Two callers, each reporting its own process only: the main process via a new ComapeoCoreApplicationLifecycleListener, the FGS from ComapeoCoreService.onCreate. Both run off the main thread, and collection runs before the current run's anchors are stamped so the decoder sees the previous session's values.
• Per-process high-water timestamp dedupes across runs. First observation initialises it to "now" and emits nothing, so a device's first update never floods Sentry with the pre-feature backlog.
• oem.killer.suspected=true tags the SIGKILL-to-foreground(-service) signature of OEM custom killers reaching past FGS protection — the headline cohort, sliceable by manufacturer/model.
• exit.intentional separates user force-stops from system kills so kill-rate dashboards can exclude them.
• Wall-clock anchors (BackgroundAnchors, stored in the shared prefs file so the FGS can read the main process's background state; ProcessLifecycleOwner ON_STOP/ON_START maintains backgrounded_at) derive uptime_bucket / bg_duration_bucket coarse tags + exact-ms extras, and comapeo.fgs.killed_in_background.
• Pre-API-30 devices set a one-time exitReasons.supported=false scope tag and no-op.

iOS (Phase 7a)

AppExitMetricsCollector subscribes to MXMetricPayload — the MetricKit metric side sentry-cocoa deliberately skips (their SentryMetricKitIntegration only covers the diagnostic side) — and forwards MXAppExitMetric buckets as "ios exit: <cohort>_<bucket>" events with exit.cause_class / exit.intentional tags and a stable window_id. The decode logic (AppExitDecoder) is MetricKit-free, so it compiles and is unit-tested on macOS via swift test; the MXMetricManagerSubscriber adapter is #if os(iOS).

Phase 9b.8 tier reclassification (shipped here, not deferred)

The duration-derived Android fields and the iOS per-exit duplication only flow when captureApplicationData is on; the records themselves ship at the diagnostic tier.

Divergences from plan

• Pre-iOS-14 appExitMetrics.supported=false branch dropped — the podspec floor is iOS 15.1, so it was dead code.
• One emission helper per platform (Sentry.captureEvent on Android serves both processes; SentryNativeBridge.captureMessage gained an extras param) — deliberately a single seam for the planned migration to Sentry Application Metrics once the native pins reach the metrics floors (sentry-android ≥ 8.34, sentry-cocoa ≥ 9.12); see the Phase 8 note in the plan.

Tests & validation

• 25 new JVM tests (high-water behaviour, tag/level/tier mapping, bucket boundary cases, decode-table coverage incl. unknown-int fallthrough).
• 11 new Swift tests (per-exit duplication semantics, tier gating, cause-class/level mapping, unknown-bucket fallthrough, window-id stability).
• Validated live on an API 34 emulator: SIGKILLed the FGS while foreground-service (the OEM-killer signature) and the main process while backgrounded; each kill surfaced exactly once on the next start with the high-water mark advancing to the exact record timestamp. Pre-30 fallback probed on an API 29 emulator (clean no-op). iPhone 16 simulator confirmed the MetricKit subscription at launch (payload delivery isn't testable in simulator/TestFlight — App Store builds only).
• Empirically discovered + documented: the system persists exit records asynchronously, so a START_STICKY restart ~2s after a kill can see nothing (record surfaces next start), and in a rapid kill→restart burst the first record can be skipped permanently. Added to the §7.5.1 caveats.

Phase 7b (UserDefaults killed-in-background heuristic) stays in the plan as optional follow-up.

🤖 Generated with Claude Code