Play: user-perceived crash rate 3.64% exceeds the 1.09% bad-behavior threshold

[TimeToBuildBob]

Play Console flags the app under Technical quality → Bad behavior: user-perceived crash rate 3.64% against Google's 1.09% threshold, which reduces discoverability. Per-version crash clusters from the Play Developer Reporting API, last 7 days (2026-09-07 → 09-14):

versionCode 40 (v0.14.0b2, the bulk of installs)

reports	users	cluster	status
532	91	BackgroundService.onCreate → ForegroundServiceStartNotAllowedException	fixed by #257, shipped in v0.14.1
9	6	AlarmReceiver.onReceive → ForegroundServiceStartNotAllowedException	fixed by #257, shipped in v0.14.1
57 + 26	1 + 3	libaw_sync.so Rust panic → SIGABRT	open, #220
31 + 6	1	Java_net_activitywatch_android_… JNI entry in libaw_server.so → SIGABRT	open (a Rust panic unwinding across the extern "C" JNI boundary aborts the process)
22	3	libaw_server.so → SIGABRT	open, same class
16	8	AccessibilityNodeTraversal.findNode → StackOverflowError	open (recursive traversal, no depth bound)

versionCode 41 (v0.14.0): no crash clusters; that release's problem was ANRs (#261).

versionCode 33 (v0.12.1, 2023): 324 reports / 61 users on ChromeWatcher.onAccessibilityEvent NPE plus 8 on ChromeWatcher.onInterrupt. The class no longer exists; only the update to 0.14.x fixes those users.

What this means for the metric: the largest cluster by far (541 reports, 97 users) is already fixed in v0.14.1, so the rate should drop substantially as it rolls out. The v0.12.1 stragglers will keep a floor until they update. The remaining actionable work:

1. Native panics must not abort the process: wrap every JNI entry point in libaw_sync and libaw_server with catch_unwind and return an error object (a Rust panic reaching extern "C" is an abort since Rust 1.81). Fixing the underlying #220 panic is the second half.
2. findNode / forEachNode: iterative traversal with a depth and node budget instead of unbounded recursion.
3. Re-check this metric two weeks after v0.14.1 is at 100%.

[ErikBjare]

v0.14.1 just went live on prod track in Play Store, will be interesting to see how it does!

I am personally running the v0.14.2b1 on my device, which is running smoothly!

[TimeToBuildBob]

Confirmed: production is versionCode 42 (v0.14.1) at 100%. Internal is 43 (v0.14.2b1). Glad 43 is smooth on-device — that build already has #269 (bounded findNode); prod 42 does not.

Fresh Play Reporting snapshot (2026-09-15, API latest complete day is 2026-09-13 so today's rollout is not in the series yet):

• 7-day userPerceivedCrashRate avg: 1.37% (was 3.64% when this issue opened). Still above the 1.09% bad-behavior line.
• 28-day simple avg of the same daily series is still ~3.2% — mid-August days were 7–14%. If Console's headline is the longer window, it will not clear until those days roll off (~end of September), even if recent days stay low.
• Last complete day (2026-09-13): 0%.

7-day crash clusters, same ranking as the opener, counts still leftover-dominated:

reports	cluster	status
426	BackgroundService.onCreate FGS	fix in 42; draining from vc40
288	ChromeWatcher.onAccessibilityEvent NPE	v0.12.1 only; updates are the fix
~130	libaw_sync / libaw_server SIGABRT	ActivityWatch/aw-server-rust#681 (catch_unwind on JNI) is merged but not in the aw-android submodule — v0.14.1 and v0.14.2b1 both still pin 5e67ac8 (#679); #681 is 2 commits ahead
15	findNode StackOverflowError	fixed in 43 via #269, not in prod 42

So the rate drop so far is mix-shift + FGS drain, not the remaining native/traversal work. Next Android cut should bump aw-server-rust past ActivityWatch/aw-server-rust#681. Rechecking this metric in two weeks, once 42 has a full vitals window.