Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

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

Open
  • Is something wrong?
#267 2 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
45/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
kotlin, rust
Domain
backend, mobile

Research direction

Start with the JNI entry points in libaw_sync and libaw_server, then inspect AccessibilityNodeTraversal.findNode and forEachNode. Review the open #220 panic and the reported recursive traversal failures. Done means native panics no longer abort through JNI, traversal has depth and node limits, and the Play crash metric is rechecked after v0.14.1 reaches full rollout.

Written by the indexing model from the issue text.

Description

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%.
Dominant language
Kotlin
Stars
270
Forks
57
Avg merge
23h 47m
Merged PRs (30d)
39

Getting set up

We have not checked this project's setup files yet. Start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from ActivityWatch/aw-android

All issues in ActivityWatch/aw-android

Similar issues

More Kotlin issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.