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

aw-notify support: activity-based notifications on Android

Open
  • Is something wrong?
#196 3 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Quiet
Tech stack
kotlin, rust
Domain
backend-api-design, mobile

Research direction

This is a design issue requiring discovery before implementation. Start by reading the aw-notify desktop project to understand rule semantics. Examine the aw-android codebase for the aw-server-rust API integration and existing notification handling from PR #195. The goal is to produce a design document answering the listed discovery questions, not to write code yet.

Written by the indexing model from the issue text.

Description

Problem

Add aw-notify support to aw-android so users can opt into activity-based notifications such as per-app time alerts or category-budget nudges. The Android product behavior is not specified yet; this issue should define that behavior before implementation rather than assume a direct port of the desktop daemon.

PR #195 provides the Android 13+ POST_NOTIFICATIONS permission needed for any user-visible notification.

Discovery scope

Before choosing an implementation, answer:

  • Which first notification use case delivers enough value to ship?
  • Is the rule engine shared with aw-notify, ported, or Android-specific?
  • Where are rules configured, and how can users disable or snooze them?
  • What cadence and execution mechanism preserve battery life and Android background limits?
  • Should evaluation query the local aw-server-rust API, consume watcher events directly, or use another boundary?
  • How do quiet hours, duplicate suppression, timezone changes, and Do Not Disturb behave?

Candidate MVP (not yet committed)

A WorkManager periodic task could evaluate one locally configured threshold against the on-device aw-server-rust data, post via NotificationCompat, and persist enough state to avoid duplicate alerts. Android periodic work has a 15-minute minimum interval, so this is appropriate for coarse summaries or budgets, not exact real-time limits.

Acceptance criteria

  • A concrete MVP use case and rule semantics are documented
  • Notification opt-in/configuration UX is specified
  • Scheduling, battery, and Android background-execution trade-offs are documented
  • Duplicate suppression, quiet hours, timezone changes, and unavailable local server are covered
  • The implementation boundary relative to desktop aw-notify is decided
  • A scoped implementation issue or PR is created from the design

Out of scope

  • Implementing all desktop aw-notify features in the first Android slice
  • Server-driven or cross-device notifications before sync is ready
  • Treating the always-on foreground-service status notification as an aw-notify feature

Related

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.