Play Store rating collapse (4.2→3.1) is driven by the ChromeWatcher.kt:76 NPE — data

[ErikBjare]

The Play Store rating is collapsing, and the data points at one specific crash

We now auto-collect Android vitals + rating history in ActivityWatch/stats (see ActivityWatch/stats#17). Pulling it together makes the picture clear.

Rating is in free-fall (data/android-ratings.csv)

Date	Store rating
2019	5.00
2022–2024	~4.4–4.5
Jan 2026	4.21
Jun 2026	3.15

A ~1-point drop in ~6 months.

Crash rate spiked over the same window (data/android-crash-rate.csv)

User-perceived crash rate ~8–9% (over Google's ~8% bad-behavior threshold); raw crash rate ~15–27%/day. User-perceived ANR is ~0% — this is a crash problem, not ANR.

One crash dominates (vitals.py errors)

Reports	Exception	Location
791	NullPointerException	ChromeWatcher.onAccessibilityEvent (ChromeWatcher.kt:76)
26	NotImplementedError	ChromeWatcher.onInterrupt
~22	SIGABRT	libaw_server.so (Rust OOM)

The #1 cluster (791) dwarfs everything else combined. Stacktrace:

Exception java.lang.NullPointerException:
  at net.activitywatch.android.watcher.ChromeWatcher.onAccessibilityEvent (ChromeWatcher.kt:76)
  at android.accessibilityservice.AccessibilityService$2.onAccessibilityEvent (AccessibilityService.java:2744)
  ...

Conclusion

The rating collapse tracks the crash spike, and the crash spike is essentially one NPE at ChromeWatcher.kt:76. So the highest-leverage lever for both crash rate and rating recovery is:

1. Null-guard ChromeWatcher.kt:76 (onAccessibilityEvent).
2. Cut a fresh release from master (~124 commits ahead of the 2023 Play build; already carries merged ANR fixes).

That one fix + a release should take the crash rate from ~9% toward the Rust-OOM floor and start the rating recovering.

Reproduce the data yourself

In ActivityWatch/stats (key already on your machine):

uv run vitals.py errors --limit 10 --stacktraces
uv run vitals.py summary
# rating history: data/android-ratings.csv

Related: #176 (crash/ANR tracking — this issue is the rating-impact analysis). cc @TimeToBuildBob

[TimeToBuildBob]

Root cause confirmed: NPE in the catch block itself

I traced the 791 ChromeWatcher.kt:76 crash reports to a single line in v0.12.1:

// ChromeWatcher.kt lines 75-77 (v0.12.1)
catch(ex : Exception) {
    Log.e(TAG, ex.message!!)  // ← line 76: NPE when ex.message is null
}

The NPE is in the error handler, not the main logic. When an exception with a null message is caught (which is the default for NullPointerException), Kotlin's !! operator on ex.message throws a second NPE at line 76. This is a classic self-defeating catch block.

Fix already in master

WebWatcher.kt (the renamed/refactored replacement) already fixes this:

} catch(ex : Exception) {
    Log.e(tag, ex.message ?: ex.toString())  // ← null-safe
}

Why a v0.12.2 hotfix won't work

v0.12.1 targets SDK 34. Google Play now rejects submissions below SDK 35, so we can't publish a patched v0.12.2 — it would fail at upload.

Path to fix reaching users

The fix is already in master as part of the ChromeWatcher → WebWatcher refactor. It reaches users as soon as v0.14.0 ships to Play Store, which is tracked in #1021. The release is blocked on two PRs that need Erik's merge:

• #179: targetSdkVersion 34→35 upgrade
• #182: SUPPLY_TRACK regex fix

Once those merge and a Play Store build goes out, the 791 crashes and rating pressure should drop substantially.

[TimeToBuildBob]

Update: release blockers are now merged

Both PRs I flagged as blocking a Play Store release have since merged:

• ✅ #179 — targetSdkVersion 34→35
• ✅ #182 — CI regex fix

Master is now in a shippable state. The fix for the 791 NPE crashes is already there (via the WebWatcher.kt null-safe catch). The next move is cutting v0.14.0 and submitting to Play Store — that's the single remaining action between the current crash rate (~9%) and a meaningful rating recovery.