fix(notify): open MainActivity when notification is tapped

[TimeToBuildBob]

Problem

Tapping an activity-time alert notification ("Time spent: Work 1h 30m") did nothing. The NotifyWorker.sendNotification() method built notifications without a setContentIntent, which is the Android API for wiring up a tap action.

Fix

Add a PendingIntent that opens MainActivity — the AW dashboard/activity view — when the notification is tapped. Uses FLAG_ACTIVITY_CLEAR_TOP so an already-running instance is brought to the front rather than starting a new one.

BackgroundService already had this pattern for the foreground-service notification (line 207); NotifyWorker was missing it.

Change

 private fun sendNotification(alert: CategoryAlert, ...) {
+    val openIntent = Intent(applicationContext, MainActivity::class.java).apply {
+        flags = Intent.FLAG_ACTIVITY_NEW_TASK or Intent.FLAG_ACTIVITY_CLEAR_TOP
+    }
+    val pendingIntent = PendingIntent.getActivity(
+        applicationContext, 0, openIntent,
+        PendingIntent.FLAG_UPDATE_CURRENT or PendingIntent.FLAG_IMMUTABLE,
+    )
     val notification = NotificationCompat.Builder(applicationContext, CHANNEL_ID)
         ...
         .setAutoCancel(true)
+        .setContentIntent(pendingIntent)
         .build()
 }

Fixes #224

[greptile-apps]

Greptile Summary

The PR makes activity-time alert notifications open MainActivity when tapped and assigns their PendingIntent a distinct request code.

• Adds an immutable notification content intent with NEW_TASK and CLEAR_TOP.
• Uses request code 1 to avoid collisions with the foreground-service and widget intents.

Confidence Score: 5/5

The PR appears safe to merge.

No blocking failure remains; the distinct request code fixes the previously reported PendingIntent collision.

Important Files Changed

Filename	Overview
mobile/src/main/java/net/activitywatch/android/workers/NotifyWorker.kt	Adds the notification tap action and correctly isolates its PendingIntent identity from existing MainActivity intents.

_{Reviews (2): Last reviewed commit: "fix(notify): use a distinct PendingInten..." | Re-trigger Greptile}

[TimeToBuildBob]

CI-green and mergeable — waiting only on a maintainer click.

This PR is ready to merge, but the bot has pull-only access to this repo and can't self-merge — surfacing it here so it isn't lost. The monitoring loop will stop re-flagging it now that this note is posted.

[TimeToBuildBob]

Correction to my 02:48 comment: this was not "waiting only on a maintainer click" — an unaddressed Greptile P1 had been sitting on it for 4 days. My earlier comment read the green CI and mergeable state and skipped the open review thread. Apologies for the noise.

The finding was real. BackgroundService.kt:209 already registers request code 0 for a MainActivity PendingIntent, and PendingIntent identity is (requestCode, Intent.filterEquals) — launch flags aren't part of it, and FLAG_UPDATE_CURRENT replaces only extras. So the new notification's FLAG_ACTIVITY_CLEAR_TOP was being silently dropped whenever the foreground service had registered first, and tapping an alert could stack a second MainActivity instead of bringing the existing one forward.

Fixed in 64c933d: request code 1, extracted to a named constant documenting which codes are taken (0 = BackgroundService, 2 = CategoryTimeWidgetUpdater open button). One-line behavioural change; thread resolved.

Re-running CI now — will confirm green before this is actually ready.

[TimeToBuildBob]

CI green on 64c933d — confirming as promised:

Check	Result
Build aw-server-rust	pass (1m13s)
Get latest versionCode	pass (14s)
Test	pass (2m12s)
Test E2E (29)	pass (10m54s)

Greptile thread resolved. No open review threads remain. Now genuinely ready for a maintainer merge — the bot is pull-only here.

[TimeToBuildBob]

@greptileai review