[Bug] Actions and dismissals stop working for notifications that predate the app process restart

[renatoaraujoc]

Describe the bug

activeNotifications in NotificationDismissalUtil is only populated from onNotificationPosted (MediaNotificationListener.kt:668). onListenerConnected() (line 448) doesn't repopulate it from getActiveNotifications().

After the app's process restarts — system kill, reboot, re-toggling notification access — notifications that are still sitting in the shade are no longer in the map. Dismissals and actions for them fail with Notification with ID ... not found, while the Mac app still lists them and reports success, so from the user's side it just silently does nothing.

To Reproduce

1. Connect and let some notifications sync
2. Force stop the app (or reboot the phone), then let it reconnect
3. From the Mac app, dismiss one of the notifications that arrived before the restart — nothing happens, logcat shows Notification with ID <id> not found
4. Dismiss a notification that arrived after the restart — works

Expected behavior

Notifications that are still active on the phone stay actionable after the listener reconnects.

Suggested fix

Repopulating the map in onListenerConnected() from getActiveNotifications() is necessary, but on its own it isn't enough — I originally assumed it would be and that turned out to be wrong on device (correction below).

Generated IDs embed postTime, and within a session the first-seen ID is preserved across updates through keyToId. Once that in-memory map is gone, regenerating from the current postTime yields a different ID than the one the client is holding, so its requests still miss. Observed after a restart: the same notification was re-registered as ..._-858577043_1785507992750 while the client still held ..._-858577043_1785507236727 — same package, same title hash, newer postTime.

For IDs to keep resolving, they have to survive the restart as well. Two ways: persist the key -> id mapping (sbn.key is stable across updates and restarts) and consult it when re-registering, or stop embedding postTime in the ID altogether (deriving it from sbn.key), which is protocol-visible and a bigger call.

Environment

• Device: Samsung Galaxy Z Fold7 (SM-F966B)
• Android Version: 16
• App Version: 4.0.0 (versionCode 30) — Mac app 4.0.0

Additional context

Found while debugging #136 (separate root cause — that one affects action buttons even on freshly posted notifications). Verified with dumpsys notification: dismissing a freshly posted notification took the YouTube count from 20 to 18, while the same call on an older ID did nothing — so the dismissal path itself is fine, it's the lookup table that's empty.

[renatoaraujoc]

Correcting myself: the "suggested fix" in the original description was wrong, and I've edited it.

I assumed that re-registering from getActiveNotifications() would reproduce the IDs a client already holds. It doesn't, for any notification that was updated after the client first saw it — the ID embeds postTime, while the client's copy is the first-seen ID that keyToId preserves across updates. Once the process dies, that mapping is gone and re-registration mints a newer-timestamped ID, so the client's requests keep missing.

I only caught this because the first patch I wrote looked like it worked — 124 notifications re-registered on listener connect — but comparing the IDs against what the client held showed none of them matched.

Fixed in #138 by persisting the key -> id mapping and consulting it when re-registering, since sbn.key is stable across updates and restarts. Verified on device: an ID the client held before a force-stop comes back identical afterwards instead of being regenerated.