[Android]: Notification plugin context lost - runtime bug

[aryajur]

• I tried searching Solar2D forums for the solution.

Describe the bug
plugin.notifications.v2 persists each scheduled notification's payload in getCacheDir()/.system/NotificationSettings.xml and embeds only the integer notification ID in the PendingIntent. When Android wipes the cache directory between scheduling and tap — which happens routinely on Android 12+ under App Standby Buckets, and aggressively on Samsung / Xiaomi / Huawei / Realme devices via OEM battery-saver routines — the lookup at tap time fails. The notification card stays visible in the system tray, the user taps it, the app cold-starts, but system.launchArgs.notification arrives nil and the user's tap is silently dropped.

Storing notification metadata in getCacheDir() is documented by Android as subject to deletion at any time (Android Developers: Internal-cache files). The fix is a one-line change.

To Reproduce

1. Schedule a local notification with a custom payload via plugin.notifications.v2.scheduleNotification(...) for ~12 hours in the future.
2. Let the app's process get killed (force-stop, or just let it idle on a Samsung / Xiaomi device for several hours).
3. Wait for the notification to fire and remain in the system tray.
4. Wait long enough for cacheDir to get cleaned (overnight is reliable on Samsung OneUI).
5. Tap the notification card. The app cold-starts.
6. Observe system.launchArgs.notification is nil.

A 2-minute equivalent (force-stop, schedule 2 minutes out, tap) works perfectly. The difference is exclusively how long cacheDir had to be cleaned.

Expected: system.launchArgs.notification populated with the notification's custom payload, like the warm-resume path.

Actual: system.launchArgs.notification is nil. The Lua-side launch handler can't tell the user even tapped a notification, so it routes through the normal cold-start flow and the user's action is silently dropped.

Target platform and where build was made:
Samsung Galaxy S24 Ultra, Android 16, OneUI 7

Additional context

2026-04-26 20:51:19 [INFO] Notification event received: type=local
2026-04-26 20:51:19 [INFO] Daily notification received: feedback_evening   (working — app warm/inactive)
2026-04-27 13:23:17 [INFO] Notification event received: type=local
2026-04-27 13:23:17 [INFO] Daily notification received: muhoort_morning    (working — app warm/inactive)
                            [ ~18 hours of process death ]
2026-04-28 07:10:28 [INFO] Notifications service initialized               <-- main.lua just started
2026-04-28 07:10:28 [INFO] OAuth deep link handler registered
2026-04-28 07:10:30 [INFO] Normal flow: routing based on login status      <-- no notification path
2026-04-28 07:10:30 [INFO] User logged in - navigating to calendar

The user reported tapping the feedback_evening notification card at ~07:10 (visible in the tray from the previous evening). system.launchArgs.notification was nil — no App launched from notification log line, no Notification event received between the two clusters. The card produced a launch, but the payload was lost while the device was idle overnight.

Proposed fix

Move the persistent settings file from cacheDir to filesDir. getFilesDir() is part of internal storage and is not subject to opportunistic cleanup (Android Developers: Internal storage):

- new java.io.File(getApplicationContext().getCacheDir(), ".system")
+ new java.io.File(getApplicationContext().getFilesDir(), ".system")