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

aw-notify: settingsStore integration and shared webui config surface

Open
  • Is something wrong?
#201 22 comments 0 reactions 1 assignee View on GitHub

Maintainers usually reply within 1 day

@TimeToBuildBob is already working on this.

Since Jul 25, 2026.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
45/100
Issue type
Feature
Clarity
Clearly specified
Activity status
Active
Tech stack
kotlin, python
Domain
backend-api-design, mobile

Research direction

The NotifyWorker in the Android app currently uses hardcoded DEFAULT_ALERTS. First, examine the aw-notify desktop Python daemon to understand its config model. Then, look at the server-side settings API endpoint (/api/0/settings/aw-notify/alerts) to see how to store and retrieve config. The work involves modifying the Kotlin worker to read from this API, creating a fallback default, and ensuring the webui can expose a compatible config panel. 'Done' means the Android app uses server-stored alert configuration shared with the desktop client.

Written by the indexing model from the issue text.

Description

Follow-up to #199 (merged) — centralising alert configuration so Android shares the same config surface as aw-notify on desktop.

What's missing from the MVP

The NotifyWorker shipped in #199 hardcodes DEFAULT_ALERTS directly in Kotlin. The only server-side setting it reads is startOfDay. Everything else (categories, thresholds, enabled/disabled) requires a code change.

Goals

  1. settingsStore integration — store alert config under /api/0/settings/aw-notify/alerts (or a sub-key of the existing settings namespace). The Android app reads this at worker startup instead of the hardcoded list, matching the server-side config model aw-notify desktop already uses.

  2. Shared webui config surface — once the config lives in the settings API, the aw-webui can expose a config panel identical to (or compatible with) the desktop aw-notify settings, so users manage thresholds in one place regardless of client.

  3. Reduced default thresholds — the current defaults (All at 1h/2h/4h/6h/8h, Work at 15m/30m/1h/2h/4h, etc.) are too dense for most days. Trim to 2–3 thresholds per category max, or align with whatever the desktop aw-notify defaults converge to after #200 lands.

  4. Migration path — if a user has no server-side config, fall back to a minimal built-in default (not the current verbose list) so first-run behaviour is conservative.

Out of scope here

  • Anomaly/percentile-based notifications → tracked in #200
  • App-layer quiet-hours (the OS aw_notify_channel + DnD is sufficient for now)

Cross-references

  • #199 — the initial notify implementation (merged)
  • #200 — smart anomaly-detection notifications (v2 direction)
  • aw-notify desktop — the Python daemon this should share config with
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.